Re: The evils of /usr/share/java/repository
On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
> Jeff Turner <jeff@socialchange.net.au> writes:
>
> > If you want other jars to be considered "standard", put them in
> > $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> > of what you're proposing.
>
> I'm proposing that the policy is that jars should be installed in
> $JAVA_HOME/jre/lib/ext/, except that it should install in a
> directory not specific to JDK. I.e. there should be an "extensions"
> that in effect all JVMs search or some equivalent mechanism.
Ah ok, I see.
> > So my claim is that a standard mechanism to achieve what you want
> > already exists, and has largely been rejected by the Java community. Or
> > at least by the section that has to deal with users' broken classpaths.
>
> You're comparing apples and oranges, I think. Or at least I don't see
> how not providing a classpath at all is going to fix users' broken
> classpaths.
A clean classpath is a conflict-free classpath :) A clean classpath wouldn't
have cost me a few hours last saturday working out what Tomcat wouldn't start.
>
> I agree that when an application is installed it should install a
> script or whatever that looks for existing packages and checks for
> compatible versions.
I presume you're talking about packaged apps. Yes, they could do a 'dpkg -S' or
whatever to determine a conflict. I'm more concerned about the vast majority of
software that isn't packaged, but still needs to run on Debian systems. To
"look for existing packages" and "check for compatible versions" is simply not
possible.
Instead, what startup scripts DO do, it assume a clean classpath, and add their
requisite jars. Every startup script I know does this. This "clean
classpath" model is so deeply entrenched that providing a system
classpath can do nothing but harm, in the form of conflicts.
[snip]
> > That's half of my complaint; if you do it
> > in /usr/bin/java, it cannot be overridden.
>
> My proposal does not say anything about /usr/bin/java, except that
> the default classpath should include jars of installed packages.
> I am agnostic about the specifics of how that is done.
Sorry, I've been thinking you were advocating the current state of affairs,
where the classpath is set inside /usr/bin/java. As such, there is absolutely
no way of getting around of it. If you want to set a default classpath in
/etc/profile, or another overridable place, I'll stop whining and go away ;)
> > Most Java programs are largely independent of environment as well as
> > platform. Their only requirement for the environment is a JRE, and
> > occasionally some standard Java extensions.
>
> Have you looked at the build instructions for Tomcat? That is an
> awful lot of dependencies. (Way too many of course. and not clear
> which are required and which are optional.)
Yes, but have you looked at how those dependencies are specified? All neatly in
a build.properties file.
Note well: the user is NOT expected to have their classpath preset.
It was not always so. A year ago, many projects did require you to set a
classpath. However, people have found that explicitly listing jar dependencies
is *much* better, hence the shift. This is what I meant in my original email
"if the Java community has learned anything, it's that **classpaths are
evil**."
Have I convinced you yet? ;P System classpaths are obsolete. They were a bad
idea to start with (because not all systems have a notion of env variables),
they are a bad idea in practice (because they cause version conflicts), and 6
years on, most of the industry has realised this and developed alternatives.
However, if I haven't convinced you, fine; just please allow me a way to
override the default. Anything is better than the existing situation.
> > As you can see, my situation (and I suggest, that of most Java
> > developers) is vastly different to that of C/C++ developers. Apples and
> > oranges. What works for C/C++ won't work for Java.
>
> I agree that Java is fundamentally broken is that there is no way to
> specify default implementations for interface methods. That means
> tere is no way to extend an interface without breaking old clients..
> The servlet API is of course notorious in this respect. C/C++
> doesn't have this problem, at least not to the same extent.
Ah interfaces.. how beatiful they seemed after the kludgery that is C++
multiple inheritance ;)
--Jeff
> --
> --Per Bothner
> per@bothner.com http://www.bothner.com/per/
Reply to: