Re: The evils of /usr/share/java/repository
Jeff Turner <email@example.com> 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.
> 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
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. Similarly, when a library package (jar) is
installed, it should check that prerequisite packages are compatible,
with compatible versions.
> The equivalent of -nostdinc in Java is 'unset CLASSPATH'.
'unset CLASSPATH' still leaves the builtin classpath and the
installed extensions in the classpath.
> It is not possible with your proposal.
Huh? What I am proposing that the default classpath include jars of
installed packages. That does not preclude a mechanism for overriding
the default classpath or having a null initial classpath (but not as
the default). There are many ways to do that.
> 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.
> 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.)
> 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.