8

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

Asaph
  • 159,146
  • 25
  • 197
  • 199
sarahTheButterFly
  • 1,894
  • 3
  • 22
  • 36

3 Answers3

7

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.

Bozhidar Batsov
  • 55,802
  • 13
  • 100
  • 117
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.

1

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

Community
  • 1
  • 1
cmsherratt
  • 2,129
  • 3
  • 15
  • 13