[kaffe] Poor CLASSPATH handling...

[Godmar Back]

> 
> [jsantala at yavin bin]$ export CLASSPATH=foobar.jar
> [jsantala at yavin bin]$ jar
> 
> In other words, Kaffe appears to fail/crash silently if it can't find any
> component in the CLASSPATH (And this appears to include classpaths
> specified in jar files, making most pre-bundled jar-files unusable). It
> appears this is the net problem that was keeping XSmiles/Xalan from
> running with the latest Kaffe desktop-edition builds. As luck would have
> it, I have important business elsewhere, so I'll have to leave fixing it
> to somebody else ;) (Unless it isn't fixed by the time I come back...
> altough I'm not too familiar with this part of the code, and there's no
> exceptions etc. available that early to track execution...)
> 

Somebody must have broken that then.  It still works fine for me:

 $ setenv CLASSPATH /home/gback/JPython-1.1/jpython.jar
 $ jar
 Usage: jar {ctxu}[vfm0M] [jar-file] [manifest-file] [-C dir] files ...
 Options: ....

This is with some old 1.0.6-2 rpm from Redhat.
Now if you set the CLASSPATH env var, it will not override the classpath,
just add to it.

If you completely override the classpath (that is, using
-classpath), Kaffe will complain:

$ kaffe -classpath /home/gback/JPython-1.1/jpython.jar ExecThreadTest
Couldn't find or load essential class `java/lang/Object' java.lang.NoClassDefFoundError java/lang/Object
Abort (core dumped)

If you don't like the abort(), remove it.

Kaffe was even able to detect some more subtle CLASSPATH problems, such as
when a user put Sun's classes.zip in front of Klasses.jar, or when
the wrong version of Klasses.jar was used.
(This seems to be broken in 1.0.6 already, though.)

Other than that, Kaffe's classpath handling is exactly that of JDK 1.1.
My understanding is that Dalibor is working on updating to 1.2 behavior,
but the current kaffe (or at least the version I looked at last)
did or used to do 1.1 behavior just fine.

	- Godmar