Re: The evils of /usr/share/java/repository
On Sun, Sep 16, 2001 at 04:21:09PM -0700, Per Bothner wrote:
> Jeff Turner wrote:
>
> >I can write a Hello World program just fine with a completely blank
> >classpath [1]. In fact, I can write any program that uses java.* and
> >javax.* with nothing in the classpath except the package root.
> >
> $ javac foo.java
> foo.java:1: cannot resolve symbol
> symbol : class Servlet
> location: package servlet
> import javax.servlet.Servlet;
> ^
> 1 error
My mistake; only java.* works. 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.
Now if you frequent certain Java mailing lists (eg tomcat-users), you'll
see a degree of antipathy for this lib/ext mechanism, for precisely the
reasons I'm putting forward. It is too easy to forget that you've got
something there, and then install code which requires a later version of
that jar. These mailing lists are full of classpath problems, with
suggested solutions like:
"Double check for an old copy of servlet.jar (or possibly jsdk.jar) in
your classpath, or in your system extensions directory
($JAVA_HOME/jre/lib/ext)"
"You are probably using IBM's JDK, right? Just rename or delete
%JAVA_HOME%/jre/lib/ext directory. It worked for me. IBM's JDK has an
%XML parser integrated into JDK and this parser is the problem."
"Look for an old or incorrect version of servlet.jar (or possibly
j2ee.jar) in your CLASSPATH, or in your $JAVA_HOME/jre/lib/ext
directory and remove it"
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.
> On Sun, Sep 16, 2001 at 02:16:58PM -0700, Per Bothner wrote:
>
> >Let's just suppose that some crazy people disagree with you, and don't
> >want miscellaneous libraries in their classpath.
> >
> If people want that, they can use something analoguous to gcc's
> -nostdinc option.
> However, note that -nostdinc is not the default!
The equivalent of -nostdinc in Java is 'unset CLASSPATH'. It is not
possible with your proposal. That's half of my complaint; if you do it
in /usr/bin/java, it cannot be overridden. I'd be much happier if it
happened in /etc/profile, where at least it's visible and overridable by
users.
> >Suppose these people have been burnt by class version conflicts.
> >Suppose these people get upset when moving their program to a
> >different system, and finding they were unwittingly relying on some
> >jar.
> >
> And how is this different from unwittingly relying on some .so?
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. Most come bundled with
requisite jars. As a developer, I am no different, and my projects make
no environmental assumptions beyond the JDK. I therefore like to keep my
environment clean, to ensure my projects are cross-platform.
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.
--Jeff
>
[snip]
>
Reply to: