Re: The evils of /usr/share/java/repository
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
Reply to: