tags:

views:

374

answers:

6

The compiler display warnings if you use Sun's proprietary Java classes. I'm of the opinion that it's generally a bad idea to use these classes. I read this somewhere. However, aside from the warnings are there any fundamental reasons why you should not use them?

+17  A: 

Because they are internal APIs: they are subject to change in a undocumented or unsupported way and they are bound to a specific JRE/JDK (Sun in your case), limiting portability of your programs.

Try to avoid uses of such APIs, always prefer a public documented and specified class.

dfa
Some APIs under `com.sun.*` are experimental (the original APT API was for example). IIRC, Alex Buckley has a blog on the various statuses of these APIs. But yes, in general they may change or disappear in update releases and between vendors.
Tom Hawtin - tackline
+6  A: 

Yes, because nobody guarantees that these classes or API will be the same with the next Java release and I bet it's not guaranteed that those classes are available in Java versions from other vendors.

So you couple your code to special Java version and loose at least portability.

Andreas_D
+2  A: 

Sun's proprietary Java classes are part of their Java implementation not part of the Java API their use is undocumented and unsupported. Since they are internal they can be changed at any time for any reason that the team working the Sun JVM decides.

Also Sun's Java implementation is not the only one out there! Your code would not be able portable to JVMs from other vendors like Oracle/BEA and IBM.

Tendayi Mawushe
+1  A: 

Try running your code with a non-Sun JVM and see what happens...

(Your code will fail with a ClassNotFound exception)

Thorbjørn Ravn Andersen
This is a valid suggestion to identify the problem (*although not a proper answer*).
Esko
@Esko, sigh, added an explanatory note...
Thorbjørn Ravn Andersen
+1  A: 

I recently had a case that showed a real-world problem you can hit when you use these classes: we had code that would not compile because a method it was using on a sun.* class simply did not exist in OpenJDK on Ubuntu. So I guess when using these classes you can no longer say things like 'this works with Java 5', because it will only work on a certain Java implementation.

Fabian Steeg
+3  A: 

The JDK 6 Documentation includes a link titled Note About sun.* Packages. This is a document from the Java 1.2 docs, so references to sun.* should be treated as if they said com.sun.*

The most important points from it are:

The classes that Sun includes with the Java 2 SDK, Standard Edition, fall into package groups java.*, javax.*, org.* and sun.*. All but the sun.* packages are a standard part of the Java platform and will be supported into the future. In general, packages such as sun.*, that are outside of the Java platform, can be different across OS platforms (Solaris, Windows, Linux, Macintosh, etc.) and can change at any time without notice with SDK versions (1.2, 1.2.1, 1.2.3, etc). Programs that contain direct calls to the sun.* packages are not 100% Pure Java.

and

Each company that implements the Java platform will do so in their own private way. The classes in sun.* are present in the SDK to support the Sun implementation of the Java platform: the sun.* classes are what make the Java platform classes work "under the covers" for the Sun Java 2 SDK. These classes will not in general be present on another vendor's Java platform. If your Java program asks for a class "sun.package.Foo" by name, it may fail with ClassNotFoundError, and you will have lost a major advantage of developing in Java.

R. Bemrose