Hi Joe, The suggestions here are all good and sensible, but are based on one big assumption: that the classpath should be set to *anything* in the first place.
Why not just put the jars in /usr/share/java, keep the system classpath completely clean, and let the startup scripts for individual apps choose which to include? How many apps out there don't include a startup script, but require the user to manually set up their classpath? I don't know of any, and certainly nothing of the sort should be allowed in a debian package. A system classpath represents an unchallenged assumption. When writing new code, I could be unwittingly relying on stuff in the system classpath, and when I try to compile the same stuff at work, it will all break. I'd prefer to find out right at the beginning what's wrong. --Jeff FYI, there are attempts to create a CPAN-like mechanism for managing jar dependencies. The jakarta people have one called JJAR, developed under the commons project (http://jakarta.apache.org/commons/), and the Enhydra people have this: http://aleutia.enhydra.org/index.html On Fri, Sep 14, 2001 at 02:35:18PM -0700, Joe Emenaker wrote: > > 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
