Hi,

I've been using my own classloader in some tests, and ran into
problems with Kaffe's classloader, basically, the superclass pointer
in the class wasn't getting changed from a constant pool index into a
real, live class pointer.  The problem is in linkClass()
(kaffevm/classMethod.c), where the class->state is set to
CSTATE_DOING_LINK, and *then* prepareClass() is called (which won't do
anything at all because the state > CSTATE_DOING_PREPARE.)

This doesn't happen with the built-in class loader because it calls
prepareClass() at the end of loadClass().

I've got an example (all tarred up) that demonstrates the problem
in http://www.cs.utah.edu/~tullmann/superclass.tgz.

My solution was to call prepareClass() before setting the class->state
to CSTATE_DOING_LINK.  I'm not sure if this is valid though.  First
off, it seems like a race condition (if threading is preemptive) to be
checking the class->state and setting it later without any locks.
Second, in a non-preemptive threading, I'm not sure if sticking a call
to prepareClass() in the critical section has just broken it.
Actually, come to think of it, prepareClass() should probably just be
the first thing that linkClass() calls, then it should muck around
with the class state.

Hopefully this description makes some sense.  Is anyone else using
their own classloader and having (or not having) such troubles?  My
example works fine under the AIX JDK and both versions of the JDK on
Solaris.

No diff because its a single line change.

-Pat