9

In JRE, Sun's internal packages are prefixed with 2 top-level domains (sun and com). For example,

com.sun.security.jgss
sun.security.jgss

It seems pretty random to me which prefix they choose. I am curious what rules Sun uses for this.

ZZ Coder
  • 74,484
  • 29
  • 137
  • 169

3 Answers3

10

Not an answer to the question, but please be aware that you should not use 'sun' or 'com.sun' packages in your programs directly.

See Why Developers Should Not Write Programs That Call 'sun' Packages

Those packages are not part of the public API of the standard Java library, and using them might make your program incompatible with future versions of Java or implementations of Java other than the Sun implementation (and there are several implementations by other vendors, including Apple, IBM and HP).

Jesper
  • 202,709
  • 46
  • 318
  • 350
  • 1
    I don't see anything about not using com.sun.* in that document that you linked to; it only says to not use sun.*. The package designation com.sun.* just means that it is part of their own public software that they make available like any other company would. – Tom Mar 27 '13 at 21:14
  • 1
    @Jasper, you are already posted this link in another discussion [http://stackoverflow.com/questions/1906673/import-com-sun-image-codec-jpeg/1907060#1907060] but the linked document is just about "sun" packages, not "com.sun" ones. Can you please update the link if you can provide one that actually tells not to use "com.sun" packages ? – danidemi Feb 11 '15 at 09:57
7

The "com.sun" convention is the more preferable format because it follows the "naming conventions" that have been established for naming Java packages.

http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html

You're supposed to use your unique company or personal website URL as the first few words in the package to guarantee uniqueness in the namespace. The ones that start with "sun" were probably not intended to be exposed to the outside world.

Andy White
  • 86,444
  • 48
  • 176
  • 211
1

If you take a glance at the compatibility document for Java 5 you'll notice that there are other reasons too:

Apache - The org.apache classes, which have never been supported J2SE APIs but are used by the javax.xml package, have moved in 5.0 to **com.sun.**org.apache.package.internal so that they won't clash with more recent, developer-downloaded versions of the classes.
Any applications that depend on the org.apache classes being part of the J2SE release must do one of the following to work in 5.0:
* Code the application so it uses only the supported interfaces that are part of JAXP.
* Download the org.apache.xalan classes from Apache.

Ryan Fernandes
  • 8,238
  • 7
  • 36
  • 53