Re: The evils of /usr/share/java/repository

[Bill Wohler <wohler@newt.com>]

Ben Burton <bburton@mail.math.okstate.edu> 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 <wohler@newt.com>  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.