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
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
Reply to: