First off, sorry this is so long-
I wrote to the list a while back regarding a NetBeans module failing to run on Apple's Java, but not Sun's. Figured out the issue, and thought I'd share in case this can help anyone else (Also, could use help if I'm understanding this wrong). Here's what I figure is going on:
Looks like Apple's Java 5 uses Apache Crimson to implement JAXP.
Crimson has Xalan and Xalan has an XML corruption bug that shows up in certain cases. Namely a few NetBeans modules. Specifically, Sun's IDM module, which I need to use.
Not such a bad thing, because JAXP allows you to swap out the built-in JAXP implementation with your own. So one should be able to drop a new processor / parser into the classpath.
But interestingly enough that's what Apple did to get JAXP to use Crimson in the first place. Instead of replacing Xerces with Crimson, they put Crimson in a library in a hidden directory inside of a system framework, and include this in the bootloader's classpath. This causes JAR Service Provider discovery to override the existing Xerces implementation.
Here's the thing:
Crimson is now sitting in the classpath and I can't get it to leave.
Even if I put a different JAXP implementation in the Extensions folder, it's only ADDED to the classpath instead of overriding the one the system uses.
So in that case, the VM just picks an implementation from the ones available... In a seemingly random way. Which is why any code susceptible to this bug has to bail if it's on the classpath. No way to know which parser you'll get when you call DocumentBuilderFactory.newInstance().
The only way I've come up with to solve the problem is to hack the JavaVM framework and move 14compatibility.jar out of the way. Any other way around this issue/bug?
What about running Java with an explicit bootclasspath which doesn't include 14compatibilit.jar? BTW, can you please recall me which are the symptoms of the problem?
