Andrew Wason wrote: > > Sun is bundling a version of Xalan and Xerces into JDK 1.4s rt.jar. > http://developer.java.sun.com/developer/bugParade/bugs/4624775.html > > But the org.apache.* packages are not part of the JDK API spec and are not > in the endorsed standards set.
Correct. The following is my understanding (but I have been known to be wrong in the past). > > "The java.*, javax.* and org.* packages documented in the Java 2 Platform > Standard edition API Specification make up the official, supported, public > interface." (the org.apache.* packages are not in the spec) > http://java.sun.com/products/jdk/faq/faq-sun-packages.html > > "No other packages from the J2SE platform API specification may be > overridden." (the org.apache.* packages are not in the overridable list) > http://java.sun.com/j2se/1.4/docs/guide/standards/index.html Notice that it says "J2SE platform API" specification here. Further down the page it states: "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..." That clause does allow you to override the implementation packages also. If you think about it, allowing API packages to be overridden but not implementation packages does not make sense. For example, it clearly allows API interface classes in org.w3c.dom to be overridden with newer versions. However, if the newer version adds a new method say Document.someNewMethod(), then that implies the current code in the JDK that implements Document must also supply the new method. That current code happens to be under org.apache.*, but in general it can occur in any package. Therefore, it necessarily means that implementation packages can also be overridden. Because, the implementation classes can be in an arbitrary package the Java Virtual Machine (JVM) does not enforce which packages can be overridden. The license is used to enforce the requirement instead. By license, I believe that means something like, if you ship a J2SE implementation and call it "J2SE 1.4" then it must conform to the J2SE 1.4 API spec. This allows apps that depend on the J2SE 1.4 API spec to be portable across any product called "J2SE 1.4". BTW, the lib/endorsed mechanism in Sun's JVM is implemented by the same mechanism as -Xbootclasspath. I agree that the page could be improved to explain this. Perhaps you can send that in as feedback. > > I think this means that I am not allowed to replace the Xalan > implementation that ships with JDK1.4 (e.g. by forcing my xalan.jar first > via -Xbootclasspath/p:). I don't think I would want to do this anyway since > it would replace internal JDK implementation classes with a version the JDK > was not tested with. Also doing this makes things more difficult for my > apps users since I can't just ship an executable jar file with a > "Class-Path: xalan.jar xerces.jar" entry in its manifest. Since it sounds like you are distributing an application and not a J2SE implementation, you can safely tell users to either use the lib/endorsed method or the non-standard -Xbootclasspath approach that may not be supported on all JVMs. You can also write your own ClassLoader code to do what you want. > > In addition, since the org.apache.* packages are not part of the JDK 1.4 > API spec (they are just part of it's internal implementation like the sun.* > packages), this means I should not use internal JDK implementation Xalan > classes like org.apache.xpath.XPath. I consider this a separate problem which I need to look more into. Certainly, if you are distributing a simple app, you can use any of the previous methods to get it to work. However, if you are distributing a webapp that will run in a container and the webapp requires a particular version of the XPath package, then what happens will depend on the container you are running in. Someone else on this thread pointed to a BEA WebLogic note about a similar issue. > > So it seems that as of JDK 1.4 I can no longer "legally" use Xalan at all - > I can't use the built in implementation and I can't replace it with my own. > Sun has usurped the org.apache namespace for their internal JDK > implementation, shouldn't they be using sun.org.apache or something? Or > possibly they could load their internal implementation classes > (org.apache.* and sun.*) via a different ClassLoader so those classes are > not visible to my application, freeing me to use my own xalan.jar without > conflicting with or replacing Suns version. I think I've addressed this question as the first issue above. -Edwin
