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

["Joe Emenaker" <joe@emenaker.com>]

> > I would argue all classpath manipulation should be done in JVM/compiler
> > startup scripts and Java application startup scripts.
>
> I think you're right.

Me, too. And this has been what I've been pushing for from the get-go.

>  1) What happens when classpath conflicts arise? Say I've installed
>  package 'lib-foo-java'. I now download two programs from their
>  respective CVSs. One requires foo.jar v1, the other requires foo.jar
>  v2. How is it possible for both apps to be able to run on my system?

Same way that servlets do it, with different local 'lib' directories. The
auto-discovery code in the JVM startup script would check to see if some
project-level variable (like $JAVA_PROJ_LIB) pointed to a directory and, if
so, it would add any jars in there to the beginning of the classpath. It
would then check to see if some user-level variable (like $JAVA_USER_LIB)
pointed to a directory and, if so, would add any jars in there right after
the project-level stuff. Then, after all of that, it would add the
system-wide stuff.

So, I could put the different foo.jar files in the different 'lib'
directories of my projects and then just change my $JAVA_PROJ_LIB between
projects. Or, for even less trouble, I could permanently just set my
$JAVA_PROJ_LIB to "./lib" and all I'd need to do is just 'cd' to the other
project's directory and I'd be automatically using the other foo.jar.

> Assuming there is a decent answer to that, and people agree that a
> system classpath is a Good Thing:
>
>  2) How can I override the system classpath?

Personally, I'd override it by *adding* stuff to it, not by removing stuff
from it.

If I have some jars containing classes that also appear in system-wide jars,
and I want to use *my* jars, then I'd put them in my $HOME/lib or
$JAVA_PROJ_LIB or something. Provided that the auto-discovery code in the
JVM's startup script was sane, it would put those jars in *front* of the
system-wide ones. So, I'd get to use mine.

Note here that there's not really any harm in having redundant or different
versions of classes in jars that appear later in the classpath, since the
JVM is supposed to take the first one that it comes across. The biggest
problem I can forsee is that there will be more jars to look through when
looking for something that *isn't* there. In other words, it will take a few
more tenths of a second before you get a ClassNotFound exception.

- Joe