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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
