> 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
