The Lurker

The Java endorsed libs XML problem

posted by ajf on 2003-01-04 at 06:36 pm

I've been meaning to write a rant about Java 1.4's "Endorsed Standards Override Mechanism" for a while.

I read that page for the first time today, and it actually made the endorsed directory sound like a good idea. For a moment, I began to believe that the problem was not with Sun, but with abuses of the mechanism. But then the last paragraph on that page caught my eye:

In addition to the packages listed above, which are part of the J2SE specification, users of Sun's J2SE Reference Implementation may be allowed to use the Endorsed Standards Override Mechanism to override implementation-specific classes such as the org.w3c.dom sub-packages delivered in Sun's Reference Implementation. See the corresponding license for details.

This immediately raises two questions:

If it is supposed to be possible to replace the Sun JVM's default implementation classes, why did they include them in rt.jar, which is very difficult to override?
Why would you recommend reading a license (without bothering to provide a link to it, I note) for details on a technical problem?

Outside of that troubling sentence, the endorsed mechanism doesn't seem like such a bad idea.

That release note lists 33 packages which are supposed to be affected by endorsed. Four of them are XML-related: the W3C DOM Java interfaces, and the three SAX2 packages. (The others all seem to relate to CORBA. Given that there are twenty-nine packages in that list, and only one of them even bothers to follow the standard Java package naming convention, I am incredibly relieved that I never deal with CORBA.)

This comment in bug 4768681 from Sun's bug tracking system describes the issue well:

xxxxx@xxxxx 2002-10-29 06:42:27

Re. overriding java.endorsed.dirs - this is not exactly suitable, I think. The problem is not that the JDK 1.4 impls of XML classes are *bad*. In most cases, most of NB [NetBeans -ajf] works fine with them. The problem is that they are *visible* despite not being part of the JRE platform, and thus that particular modules which wish to use particular impls can't. Changing the impl in the endorsed dir does not solve the problem; it just means that some particular xxxxx module, rather than the JDK, will force all other code in the VM to use the same parser impl classes. What is desired is for there to be *no* impl classes visible by default.

I believe that it would be a simple change to remove Crimson and Xalan from rt.jar. The documentation for SAXParserFactory specifies the order it uses to search for a SAXParserFactory implementation. If none of the other parser configuration settings lead to a SAXParserFactory, it falls back to using the platform default implementation class, which for Java 1.4 is a Crimson class.

There is no good reason for Crimson's SAXParserFactoryImpl to be in rt.jar; the SAXParserFactory's fallback code could easily instantiate a URLClassLoader which refers to a separate crimson.jar, a jar file which the JVM would not otherwise include in the system classpath.