Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple's JAXP & 14compatibility.jar



Hi Fabrizio, 

Thanks for writing back. The problem was / is that when I try to run NetBeans with Sun's IDM plug-in installed, I am getting an error message at load time stating that an incompatible version of Xalan was detected on the classpath and that it cannot load because of this. So NetBeans quits. (See http://wiki.netbeans.org/wiki/view/FaqXalanOnCP


I tried changing the bootstrap classpath. Didn't work, so I started digging deeper. Turns out I was wrong, and it's not getting added to the boostrap classpath.

The file is actually being appended to the APPLICATION classpath... which I don't understand at all, since isn't java supposed to respect the CLASSPATH environment variable and -cp / -classpath option??

It doesn't seem to. It takes whatever I'm supplying as an application classpath and appends the following:

:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar

So java.class.path always winds up having 14compatibility.jar in the ClassLoader search path, which pulls Crimson in.

Adam Ohren


On Apr 26, 2007, at 2:33 PM, Fabrizio Giudici wrote:


On Apr 26, 2007, at 20:18 , Adam Ohren wrote:

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?

-- 
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
email@hidden - mobile: +39 348.150.6941



 _______________________________________________
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

References: 
 >Apple's JAXP & 14compatibility.jar (From: Adam Ohren <email@hidden>)
 >Re: Apple's JAXP & 14compatibility.jar (From: Fabrizio Giudici <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.