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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
