问题
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?
回答1:
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.
回答2:
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.*
andsun.*
. All but thesun.*
packages are a standard part of the Java platform and will be supported into the future. In general, packages such assun.*
, 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 thesun.*
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: thesun.*
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.
回答3:
Try running your code with a non-Sun JVM and see what happens...
(Your code will fail with a ClassNotFound exception)
回答4:
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.
回答5:
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.
回答6:
Here is Oracle's answer: Why Developers Should Not Write Programs That Call 'sun' Packages
回答7:
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.
来源:https://stackoverflow.com/questions/1834826/it-is-a-bad-practice-to-use-suns-proprietary-java-classes