Ben Burton <[EMAIL PROTECTED]> writes: > /usr/share/java/foo-version.jar > /usr/share/java/foo.jar -> foo-version.jar
Tread carefully. This could have unpredictable results. The extension directory $JAVA_HOME/jre/lib/ext currently points to /usr/share/java, so /usr/share/java is serving as the extension directory. The extension class loader is very aggressive and looks at all classes and jars in $JAVA_HOME/jre/lib/ext *and* $JAVA_HOME/jre/lib/ext/* (which is probably what caused this repository issue in the first place). This is my impression of how it works after pouring over the sun.misc.Launcher$ExtClassLoader source. Thus, it would be a bad idea to put all versions of a jar in the extensions directory. Instead I'd put the versioned jar files in /lib/package (with all the other C versioned libraries--I don't see any reason to segregate them, except as noted above) and link to the desired version from the extension directory. Alternatively, we could put all the versions in /usr/share/java, and then make $JAVA_HOME/jre/lib/ext a directory containing jars linked to the desired version of the jar in /usr/share/java. I don't think we should mess with CLASSPATH in the scripts. This is a user-configurable variable. I don't think /etc/alternatives is a solution here. We should do something similar to the C shared library versioning. In general, I think we want to continue using the extension directory to inject jars into java and javac. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
