On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote: > 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.
My turn to say "tread carefully". Symlinking jars can be dangerous, because jars can contain a Class-path: line in their manifests. These Class-path: lines contain relative references to other jars. This causes two problems: - If the packager has gone and renamed the jar, then Class-path: references in other jars will break. - The Class-path: reference is relative (may contain ".."). Say you have /usr/share/java/jaxp.jar, and symlink it to your VM's lib/ext directory. Those relative Class-path: references are going to be relative to /usr/share/java, *not* your VM directory. So even if you symlink one jar to lib/ext, that jar may haul in a bunch of other jars. Here's someone who just got burnt by symlinking jdom.jar: http://www.servlets.com/archive/servlet/ReadMsg?msgId=143649&listName=jdom-interest "I've just spent several days tracking a nasty CLASSPATH problem created by an entry in the Beta 7 MANIFEST.MF entry. .. What makes this so evil is that the JVM's under Linux resolve symbolic links. When an symbolic link to jdom.jar is placed in some project's lib directory, both Linux JVM's still load the ../lib/xerces.jar RELATIVE to the REAL jdom.jar file." > 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. Another point about lib/ext. The JVM treats all jars in lib/ext as priveleged, like java.lang.*. "By default, installed extensions are granted all security permissions as if they were part of the core platform API" -- http://java.sun.com/docs/books/tutorial/ext/security/policy.html IOW, symlinking a bunch of jars to lib/ext is not the same as including them in the regular classpath. Now, do we really want to preclude the use of a SecurityManager in any Debian-packaged Java app? Really, there are so many complicated issues when you start trying to be clever with classpaths. I don't know half of them. I'm concerned that if Debian's java policy tries to do anything out of the ordinary, it will cause *someone* out there grief. It will then be very hard to rectify the situation. Look at the current situation with /usr/share/java/repository. So IMHO, the only safe thing to do is keep a clean classpath, put jars in /usr/share/java, and let startup scripts choose them. If you miss the ease-of-use of a system classpath, set it in your .bash_profile, or use something like http://newgate.socialchange.net.au/~jeff/jpe/ --Jeff > -- > 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.
