tags:

views:

55

answers:

2

On MacOS (at least on SnowLeopard), the java command unconditionally adds an extra jar to the classpath:

/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/.compatibility/14compatibility.jar.

This jar contains a version of Apache Xerces+Xalan, unrenamed. This can cause chaotic results for applications that are trying explicitly to use some other versions of these libraries, particularly in webapps in servlet containers.

I tried to avoid this by using OpenJDK from MacPorts, but the MacPorts build failed for it.

Has anyone worked out some other recipe, other than the obvious violence of deleting that JAR file? It's recommended on one blog, but I fear that some Apple component or another will fail without it.

+1  A: 

I believe the ultimate trump card here is -Xbootclasspath/p:foo.jar . This lets you prepend a .jar to the bootstrap classloader. This should make it take precedence over anything I can imagine. For example you can replace java.lang.String this way.

Sean Owen
Fair enough, but there's no jar to prepend. I want to get rid of this stuff, not just replace it with some other version.
bmargulies
+1  A: 

I haven't had any problems after renaming 14compatibility.jar. Perhaps you could try doing that. If anything breaks horribly, you could move it back in its original place.

Jeff