20

Like javax contains the extensions, what is the com.sun package supposed to contain?

0xCursor
  • 2,242
  • 4
  • 15
  • 33
hari_sree
  • 1,508
  • 3
  • 12
  • 24
  • 1
    Things like `com.sun.mail.smtp` and `com.sun.net.httpserver`, I suppose. http://www.google.ca/search?q=java+com.sun&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a – Ry- Dec 19 '11 at 18:31

3 Answers3

35

It contains Sun Oracle reference implementations of the standard Java (EE) APIs. Among others Mojarra (the reference JSF implementation of Oracle) and Glassfish (the reference Java EE implementation of Oracle) use this package. It's preferable to not use those classes directly in your code as it would make your code tight coupled to the implementation. Coding against the java(x) API directly enables you to change the implementation without changing your code (e.g. MyFaces instead of Mojarra and JBoss AS instead of Glassfish). Also JDK's own HttpServer sits in the com.sun.* package, see Simple HTTP server in Java using only Java SE API.

Please note that the com.sun.* package should not be confused with sun.* package which are the internal classes behind Oracle JRE which you should absolutely not import/use in your code as it would make your code tight coupled to the JRE make/version. Not using sun.* package at all enables you to run your code on all other JRE implementations (OpenJDK, GCJ, etc).

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • `java.` APIs that uses the `sun.` package - how are they staying supported when they depend on unsupported packages themselves? – Lealo Sep 30 '17 at 22:34
  • 1
    @Lealo Because they're maintained by same people. – BalusC Oct 01 '17 at 06:42
  • These people then make sure that whatever they are using from the sun.package works? Otherwise they come up with - or use other packages to replace them - thus guranteeing their own `java.` package keeps working. Did I understand that correctly? – Lealo Oct 01 '17 at 10:54
  • 1
    @Lealo They're unsupported for use by external developers. If there weren't supported at all for any use, there wouldn't be any point in their existence. – user207421 May 01 '20 at 00:21
  • 1
    @BalusC [JEP 403](https://openjdk.java.net/jeps/403) says the following, which seems to contradict your statement that it is okay to use the `com.sum.*` packages in general: "*Most com.sun.\* packages in the JDK are for internal use*". The document makes a few explicit exceptions, however. – Lii Aug 04 '21 at 21:31
  • @Lii: *.. in the JDK ..*. – BalusC Aug 05 '21 at 08:59
1

There are many places which use com.sun packages (some of which are mentioned in other answers). This answer just specifically addresses the use of com.sun within JavaFX. JavaFX is a UI library which is part of OpenJDK.

A lot of the JavaFX implementation is in com.sun classes. When JavaFX was open sourced, the following comment was made by the JavaFX developers regarding the use of com.sun classes within JavaFX:

As always, non-public API (or rather, unsupported API, meaning anything that is not in the javafx namespace such as com.sun.*) cannot be depended on from release to release. But for those of you wondering how things work, there is some very important stuff buried in the unsupported packages, and for those of you wanting to actually hack on OpenJFX, this will be of even greater interest.

jewelsea
  • 150,031
  • 14
  • 366
  • 406
  • However this only applies to JavaFX. All the JNDI and JavaMail providers are also supplied in `com.sun`, as are many other documented extensions, and they most certainly can be depended on from release to release. – user207421 May 01 '20 at 00:20
  • Yes agreed, there are certain Java components, such as javamail, for which the end user can use `com.sun` classes. But for those libraries, the relevant `com.sun` apis are part of the publicly published javadoc for the component. For JavaFX, and many other Java system components, this is not the case and `com.sun` apis in those components are reserved for internal usage, are not documented In published javadoc and should not be used by an end user. – jewelsea May 02 '20 at 23:24
-1

Packages for internal use which you are not supposed to need access to directly. They can be changed or dropped in any version of Java. You can find the source for all sun.* and com.sun.* packages in the OpenJDK.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 3
    The `com.sun` namespace is not intended for the JDK implementation: http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html – Rafael Winterhalter Apr 25 '14 at 07:12
  • @raphw can you add a link which supports your statement. Your link doesn't even mention com.sun.* – Peter Lawrey Apr 25 '14 at 09:14
  • 1
    Well, the fact they do not even mention `com.sun.*` but write an extra section on the use of `sun.*` is a first hint. Also, Sun Microsystem released all their non-JCL Java code under `com.sun`: http://search.maven.org/#search|ga|1|com.sun where the use of `com.sun` classes is obviously intended to be legal. Also, some of the JDK tools like doclets are build arround the `com.sun` namespace. – Rafael Winterhalter Apr 25 '14 at 09:33
  • "The com.sun namespace is not intended for the JDK implementation". What does that mean? com.sun is what JavaDoc dockets and taglets are specified in, as you mention in your second comment. – aliteralmind Apr 25 '14 at 10:46
  • 2
    There is an explicit warning of Oracle (and formerly by Sun) not to use the `sun.*` packages because they contain the internal JVM implementation. No such warning exists for the `com.sun.*` namespace. The only thing, the two namespaces have in common is the word *sun*. This is reflected in the accepted answer to this question. – Rafael Winterhalter Apr 25 '14 at 12:20
  • Much of `com.sun` consists of documented parts of the Sun/Oracle JDK or extensions, such as all the JNDI providers, all the JavaMail providers, the HTTP server, the Javadoc taglets, ... As such they most certainly cannot be arbitrarily changed or dropped from release to release of the JDK. – user207421 May 01 '20 at 00:19