Re: The evils of /usr/share/java/repository
On Tue, Sep 18, 2001 at 05:45:14PM -0700, Joe Emenaker wrote:
>
> > 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.
Yep, this is why my script [1] does.
# $JARDIRS A colon-separated list of directories to add jars from.
# NOT like a CLASSPATH. The most common directories will
# be included by default (see DEFAULT_JARDIRS).
# Directories may include standard shell special
# characters like '*' and '?'.
# $CLASSDIRS A colon-separated list of directories which will be
# added as-is to the classpath. Typically, this will
# include the root of your source tree, and any
# properties directories. The most common directories
# will be included by default (see DEFAULT_CLASSDIRS).
# Directories may include standard shell special
# characters like '*' and '?'.
And yes, it does work quite nicely. It's nestable too, so you can have a
~/.projrc, which will load all jars in ~/lib, and then subsequent nested
"proj.sh" invocations add to that.
> > 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.
Agreed. And the only stuff that doesn't have a startup script nowadays is new
code. Stuff you're actively working on. In these situations, there are a few
possibilities:
1 let a build tool (Ant) or an IDE manage your project classpath
2 set a system-wide classpath (may result in conflicts)
3 set a project-specific classpath (perhaps aided my a script like [1])
I don't think the Java Policy should enforce any of these solutions. Let users
decide. But if 2) is enshrined in the policy, then the implementation should at
least not prevent people from using 1) or 3). I think we all agree on that.
[..]
> > 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.
I'm not sure of my facts here, but let's say the deprecated-out-of-existence
class was in package org.myproj.utils. Now if a 2.0 class says "import
org.myproj.utils.*", won't the 1.0 class be loaded into the VM (and cause a
sealing violation) even if it's not actually used?
> 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.
Bah, that's microsoft thinking ;) I would hope that under Debian, things either
work reliably or they fail dramatically, and the problem is easy to diagnose.
> > - 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.
Well as long as there is such a mechanism, I'm a happy camper.
--Jeff
[..]
> - Joe
[1] http://newgate.socialchange.net.au/~jeff/jpe/
Reply to: