[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

 - 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

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.


> - Joe

Reply to: