Apple's JAXP & 14compatibility.jar

Subject: Apple's JAXP & 14compatibility.jar

From: Adam Ohren <email@hidden>

Date: Thu, 26 Apr 2007 14:18:19 -0400

Delivered-to: email@hidden

Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer; b=oCZg963owyg/Tw4DnLehZpSLhxvfEpCMfeURT6rhiE6ae5769Cb1yNxNBItYsIhBXhV5pSc7yqV6iTh2jPc9Ts7aj3PXQBO6bKICdGrQkNr9w/FtVYg6WyrP19ejMJIB8YV8y7VqkMv8PyjhXknVpm0EhdbfBPv6Z2NeVo3bTZo=

Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer; b=fILdxmXMMs0eWGwDx71aWAdYahVQ+i4HIaHDwBIseqzu3mhyx0TjVhQVwYdqwDv/toHcG2/VHk1Kn5XLqUpDiVJkf2lFBlBDiQdNvPnCIpXlVpy0fnzRzHzsLGjXlsRMUpucf0zIEwN3Nmk06xOsU6wGS1Mry7K6RUT1Wx+7Yto=

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?

Thanks for any thoughts,

Adam Ohren

email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Java-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/email@hidden This email sent to email@hidden

Follow-Ups:

Re: Apple's JAXP & 14compatibility.jar
- From: Fabrizio Giudici <email@hidden>