Re: The evils of /usr/share/java/repository
> But I'll spare you that ranting; let's just say I think it's a
horrifically bad
> idea to have a free-for-all in one's classpath. Developer communities
gradually
> gain experience, and if the Java community has learned anything, it's that
> **classpaths are evil**. This is *worse* than a hardcoded classpath,
because
> it's not even visible to users!
Well, there are two competing desires at work. On one hand, you want it to
be easy to make more classes/packages accessible to your JVM. On the other
hand, you sometimes need fine control over which classes your JVM can get
to.
One of the solutions to the first problem is to make some repository
somewhere where all .jar files would get added to the classpath. Then, when
you get some new jar file, you just toss it into /usr/share/java/repository
and you are off and running.
However, this solution requires a VERY careful construction of the classpath
to avoid causing the problem you just had.
The first guideline to prevent this kind of thing is to make sure that
general or system-wide features can be pre-empted by user- or
session-specific ones... and not vice versa. What this means is that all of
the /usr/share/java/respository stuff should have been put *after* the
contents of your CLASSPATH environment variable and *after* any classpath
specified on the JVM command-line.
This doesn't seem to have happened, and I think your ire is best directed in
that direction.
For quite some time now, I've felt that the classpath should be built
dynamically following a criteria roughly like this:
1 - All .jars needed for the particular JVM to operate (classloaders?
Java.lang.Object?.... etc.)
2 - Any classpath specified on the command-line
3 - Any classpath specified in environment variables
4 - All .jars completing the "standard" set of Java classes
(java.lang.String, java.util.Hashtable, etc.)
5 - Any .jars in $JAVA_LIB (or some other scheme for someone to easily
maintain a respository local to a certain application or development
project. This way, when I switch projects I'm developing, I only need to
change an env variable and I'm using all of the .jars that are salient to
that new project).
6 - Any .jars in /usr/share/java/respository.
Now, the order might not be exactly right, but I think you can see how
something *like* this would give us both ease of use *and* fine-control that
we're all after.
- Joe
Reply to: