Re: The evils of /usr/share/java/repository
> 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.
Well, you can mitigate this by making JAVA_PROJ_LIB something like "./lib"
or whatever. Then, as long as you just cd to that project's directory,
you're in good shape.
Of course, you could keep extending this like crazy. You could make the
JVM's startup script search for "./.javarc" or something and look for "jar="
entries or something. So, in essence, each project could have some config
file that the JVM script could find and use.
> 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.
Correct. I'm not suggesting that the JVM's startup script should make app
startup scripts obsolete. Heavens, no! Auto-discovery is supposed to make it
easier for use to provide jars to stuff that does *not* have a startup
script of its own.
To that end....
o Anything specified with the "-classpath" parameter to the command-line
java tools should get put in front of anything in the CLASSPATH env var.
o Anything in the CLASSPATH var should get put in front of anything in the
directory pointed to by, say, $JAVA_PROJ_LIB
o Anything in the $JAVA_PROJ_LIB dir should get put in front of anything in
the directory pointed to by, say, $JAVA_USER_LIB
o Anything in the $JAVA_USER_LIB dir should get put in front of anything in
/usr/share/java
... or something resembling this pecking order. Based upon this, any app
with a currently working startup script shouldn't break (which I consider a
good thing :) ) since startup scripts use "-classpath" parms and the
CLASSPATH env var, which will pre-empt the extra goodies that I'm
suggesting.
> 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.
Not sure I understand. I don't see a problem unless you messed up and tried
to use that old 1.0 class. With auto-discovery, the 1.0 class would
instantiate and you might get some wacky behavior. Without auto-discovery,
you get ClassNotFound. Now, some people prefer the exception because you
know immediately that there's a problem rather than having to diagnose some
strange behavior. Others would prefer the wierdness because there's a finite
chance that the app might be able to limp along and succeed at *some* level.
So, to some people, this isn't really a problem.
> - My projects are all self-contained. I don't want a system classpath
> ever, because it makes writing cross-platform projects harder.
Well, I *do* think that there should be a way to turn the auto-discovery off
(essentially making you specify *every* jar you want to use), because that's
the only way of knowing exactly which jars/classes your app is relying on.
But I consider that to be kind of an out-of-the-ordinary thing to want to
do. In the spirit of Occam's razor, I feel that it should be easier to do
commons thing and less easy to do the uncommon ones. Granted, it would be
nice if *everything* were easier but, if we must defer to one or the other,
I'd prefer to make sure that the common things are easy.
> 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.
Right, but it only needs to be how they work when you're about to port it
and you're writing the startup script.
- Joe
Reply to: