Re: The evils of /usr/share/java/repository
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
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!
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?
You've now taken away the *choice* of those people. If the classpath was
left blank, developers are free to include the following in their
personal .bash_profile:
for i in /usr/share/java/*.jar; do
export CLASSPATH=$CLASSPATH:$i
done
Requiring Java developers to modify their ~/.bashrc is not acceptable.
Now, are you feeling omniscient enough to declare that this will be fine
with *all* developers out there? That there will *never* be a situation
where an empty classpath is required?
No. However, we are talking about what the *default* should be.
I wonder why that is.. I don't remember using a 3rd party package beyond
the STL.
Some people write more complex C or C++ programs than you do. If you've
ever compiled xemacs from source you might notice it looks for a lot of 3rd
party packages.
Reply to: