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. "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 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. 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. 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. Andrew -- Andrew Wason /root/bin [EMAIL PROTECTED]
