30

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
JARC
  • 5,288
  • 8
  • 38
  • 43
  • 2
    Any functionality that is sufficiently general will be embodied in the official Java API. Is there really is something in the Sun classes that you need and cannot be done through the standard Java API? Can you give an example? – Tendayi Mawushe Dec 02 '09 at 18:46
  • (I sometimes catched myself using the internal xerces for xml processing) – Andreas Dolk Dec 02 '09 at 18:57
  • 1
    Well xerces is the default XML implementation when processing XML using JAXP. There is no need to reach down and use xerces directly. – Tendayi Mawushe Dec 02 '09 at 19:27
  • The reason I posted is because I came across some code using sun.misc.BASE64Decoder. I changed it to use codec from apache. I knew this was the right thing to do but couldn't remember why. – JARC Dec 03 '09 at 09:17
  • I want to rant about those classes all day long for causing 80% of all problems in IKVM.NET. – Jessie Lesbian Feb 07 '21 at 03:51

7 Answers7

60

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
dfa
  • 114,442
  • 31
  • 189
  • 228
  • 3
    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 Dec 02 '09 at 20:22
  • 1
    I've set my java editor (IntelliJ Idea) to exclude com.sun from intellisense suggestions.Thank you for your suggestion. – skiabox Jan 10 '13 at 16:52
  • @TomHawtin-tackline Is “APT” referring to [Academic Progress Tracker](https://docs.oracle.com/cd/E56917_01/cs9pbr4/eng/cs/lssr/concept_UnderstandingtheAcademicProgressTracker-fd7ffe.html)? – Franklin Yu Apr 09 '19 at 02:39
  • 2
    @FranklinYu Advanced Passenger Train. No, apt was Annotation Processing Tool. It briefly had it's own executable, `apt`, now part of `javac` (`-processor`, etc.) – Tom Hawtin - tackline Apr 10 '19 at 08:06
24

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.

Powerlord
  • 87,612
  • 17
  • 125
  • 175
  • 6
    As a "several years later" comment: There's no guarantee that `com.sun.*` won't change to `com.oracle.*` since Sun no longer exists. – Powerlord Oct 15 '14 at 18:33
  • 4
    That's not correct. Many `com.sun.*` packages are part of the documentated specification. It would be impossible to write JNDI LDAP or COSNaming code without them. The issue is the `sun.*` packages, which are an altogether different matter and specifically documented as such. – user207421 May 01 '16 at 05:24
  • 3
    btw, trying to use the `sun.*` and `com.sun.*` classes will fail spectacularly on Java 9. – Powerlord Oct 03 '17 at 13:45
  • 5
    Not the `com.sun.*` classes. They are documented parts of the Sun/Oracle JDK. – user207421 Jun 14 '18 at 08:30
  • I understand that `sun.*` is internal, but is there any source about `com.sun.*` being internal? And is there any example of `com.sun.*` package breaking in any version? – Franklin Yu Apr 09 '19 at 00:53
  • Related: [*What is inside com.sun package?*](https://stackoverflow.com/questions/8565708/what-is-inside-com-sun-package) – Franklin Yu Apr 09 '19 at 02:47
10

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
  • 73,784
  • 33
  • 194
  • 347
  • 4
    This is a valid suggestion to identify the problem (*although not a proper answer*). – Esko Dec 02 '09 at 20:24
  • 5
    +1 for a very practical illustration of what most would consider a hypothetical future problem – Brian May 28 '13 at 07:38
7

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 Dolk
  • 113,398
  • 19
  • 180
  • 268
4

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
  • 25,562
  • 6
  • 51
  • 57
2

Here is Oracle's answer: Why Developers Should Not Write Programs That Call 'sun' Packages

Jesper
  • 202,709
  • 46
  • 318
  • 350
  • 4
    Whilst this may theoretically answer the question, [it would be preferable](http://meta.stackexchange.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. – BoltClock Jun 05 '12 at 10:49
1

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Fabian Steeg
  • 44,988
  • 7
  • 85
  • 112