On the Practicalities page the following is stated:

Xerces is the reference DOM used for JDK 1.5 but there are still compatibility issues between the Java system libraries and other 3rd party tools and libraries.

What are some of the inconsistencies?

I ask because we have another application server in our environment that does not function correctly when the XML JARs are copied from NetKernel to our JRE installation.

Hi Jeremy,

Not sure why your existing application server is having trouble with the XML Jars that we ship with NetKernel.  They are just a set of fairly recent Apache Xerces/Xalan.

As far as the inconsistencies with the JDK.   XML integration into Java has been a bit of a saga.  In NK3.x we have retained backwards compatibility with Java 1.4.x - this was the first Java to have XML APIs and it was a real mess.  Crimson parser, bits of Xalan and worst of all they didn't move the implementation packages so the unstable mix at the core JVM classloader would override any newer versions of updated APIs that you added to the JVM.

Things are somewhat improved with Java 5/6 but even this is not great.  For some reason Sun decided to use the bytecode compiled XSLT engine that is part of Xalan as the only implementation of a JAXP transform engine.  We've seen some weird inconsistencies with this over the years and for compatibility prefer either the main Xalan transformer or Saxon - we still offer bytecode compiled engine for performance using active:xslt .  In addition the compiled xslt engine doesn't support as complete a set of XSLT parameters which can cause trouble.  In addition Java has a broken model for software engines in general - the way that the APIs look for implementations using a fallback classloader search is limited and assumes that the JVM is running a single application rather than is host to a virtualized operating system hosting multiple separate applications.

Anyway the current state of play is that we have had to take control of this layer since it is an important resource model and requires good long-term stability.  In NK3 we use the Java endorsed mechanism to ensure that our stable shipping XML libraries take priority.

If you don't want to have libraries in the JVM jre/lib/endorsed directory (where they will get loaded by default) you can alawys leave your JVM pristine and use the command line java endorsed switch to reference the libs in the NKs ext/endorsed/  directory (in fact that's how we ship it so I guess you must be talking about development time set up?).

I recently revisited this journey while working through the new NK4 XML resource model.  We were really hoping to use JAXP in an unmodified JVM environment but rediscovered these compromises in JDK 5/6 and so it looks like we'll have to ship a set of stable XML libraries again.

This is off the top of my head.  The fully story of the number of corner cases and tricks we've had to figure out to get a stable XML model is long and painful!

Cheers,

Peter

This ...

we still offer bytecode compiled engine for performance using active:xslt

should have been active:xsltc

We also have active:xslt2 - for XSLT2.0 based on the Saxon engine.  Incidentally XSLT2 has just reached recommendation status as the W3C.

Cheers,

P