On Wed, 25 Nov 1998 07:38:11 +0200, Jaco Greeff wrote:
>> Having it "fixed" in 1.2 won't help us
>
>Sorry for the total ignorance, but I've been hearing a lot about the
>CLASSPATH that doesn't need to be set in 1.2. Is this true? Where does
>"java" (1.2) look for the jar/zip/class files then? Or will it still need to
>be specified?
>
>Ok, doesn't have anything to doe with our port in general, but could
>somebody please clear this up? (I'm sure I'm not the only confuzzled person
>around here...)
Actually, in JDK 1.1, CLASSPATH does not need to be set to get the core
Java classes.zip file. The Java wrapper does that.
Also, the CLASSPATH env variable can also be set to just your own path
extensions and that will work too since the JDK will find its own classes.zip
Both of these are reasonable but the behavior of the -cp/-classpath option
*replaces* not just the CLASSPATH env variable but also the default that
the wrapper script would define and thus using that option requires that
you add in the classes.zip file, something the user should not need to
deal with.
Jikes has "yet another problem" in that it needs to know where the JDK
classes.zip file is in order to load it.
What I have done for our engineers is to state that "CLASSPATH is only to
contain local added classes" and we normally just have it set to "./obj:."
which lets us store the *.class files outside of the source tree.
All of the tools should then know how to add any tool-specific class paths
to that variable before running. The JDK tools already do this. For the
Jikes compiler I have a front-end script that does:
export CLASSPATH="${CLASSPATH}:/usr/Java/JDK/lib/classes.zip"
For the Jikes debugger, I add in the debugger classes and then call the
normal JDK Java wrapper which adds the classes.zip file.
This way, if classpath is not defined, it works as before. If classpath
is defined, I add to the end what the tool knows it will need and *if*
the user happened to want to replace part of that, the user's settings
come first.
The other thing that would be good is a standard place to put jar/zip files
(or links to them) such that you do not need to keep adding them to the
classpath in *user* space. That is, the user's environment should not
need to define things that are required definitions for the system to
operate. (Such as where classes.zip is for the JVM since it generally
does not make sense to use Java without it)
Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz
