问题
Is this statement true:
com.sun.xml.internal package is an internal package as the name suggestes. Users should not write code that depends on internal JDK implementation classes. Such classes are internal implementation details of the JDK and subject to change without notice
One of my colleagues used one of the classes in his code, which caused javac task in Ant fail to compile our project as the compiler couldn't find the class. Answer from Sun/Oracle says that this is expected behavior of the compiler as user shouldn't use the package.
Question is why the classes in the package made public in the first place?
Thanks,
Sarah
回答1:
Sun classes in the JDK are prefixed sun.* and are not part of the public supported interface so should be used with care. From the Sun FAQ:
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. In other words:
The java., javax. and org.* packages documented in the Java 2 Platform Standard Edition API Specification make up the official, supported, public interface.
If a Java program directly calls only API in these packages, it will operate on all Java-compatible platforms, regardless of the underlying OS platform.
The sun.* packages are not part of the supported, public interface.
A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.
回答2:
It's because Java visibility modifiers (especially at the type level, where there are only two options) don't currently have the granularity to achieve the sort of visibility you're hinting at. I don't know the specifics of the internal class or classes you're using, but basically making the classes private would have made them unfit for their intended purpose, so the only other choice was public.
回答3:
Sadly JAXB (bundled with Java6) seems to rely on a non-public class "com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper" to allow you to specify namespace prefixes when marshalling to xml.
You have to really go out of your way to get this compiling with ant: http://pragmaticintegration.blogspot.com/
Summary:
Option 1. Add jre libs as bootclasspathref Add property: includeJavaRuntime="yes"
Option 2. Use JAXB-RI libs - change property to "com.sun.xml.bind.marshaller.NamespacePrefixMapper"
Also mentioned here: Define Spring JAXB namespaces without using NamespacePrefixMapper
来源：https://stackoverflow.com/questions/2863043/do-not-use-com-sun-xml-internal