On Tue, Sep 18, 2001 at 12:40:01PM -0700, Joe Emenaker wrote: > > > > 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.
I have half a gig of open source Java on my hdd, which amounts to a lot of projects. With this scheme, I'd spend half my life twiddling the JAVA_PROJ_LIB variable to point to whichever project I'm currently interested in. It seems you want the "auto-discovery" mechanism to do what startup scripts currently do. But startup scripts don't *only* set up the classpath. They work out properties (-Dtomcat.home=..), set security managers, print debug info, redirect stdout/stderr, and finally invoke the main class (which is different for every project). Now I don't think you could ever subsume all that functionality. > 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. Yes that's the logical way to "override", but... > 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. I sent a mail yesterday suggesting why this isn't adequate, but an MTA somewhere is having trouble. Two problems I could think of with straight additive overriding: - If I have libfoo 1.0 in my system classpath. My program requires libfoo 2.0. However, libfoo 2.0 deprecated a certain 1.0 class out of existence. So even if they have the same package, I still have that libfoo 1.0 class in my classpath. This is not a problem unless libfoo comes in a sealed jar (like jaxp.jar), in which case I'll get sealing violations. - My projects are all self-contained. I don't want a system classpath ever, because it makes writing cross-platform projects harder. If I'm missing a jar, I want to know about it early, not when I try to port my app and find I was unwittingly relying on other jars. I submit this is how *most* projects work. There is not a single Java Apache project that relies on a system classpath. They are all self-contained, or list their dependencies in a build.properties file. There are probably other cases which I can't think of. Sorry for raining on everyone's parade, but I believe there is no safe way to have a default system classpath. --Jeff > [snip] > > - Joe
