> > 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
