> 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
