[kaffe] Problem with defineClass in a user-ClassLoader

[Dalibor Topic]

Hi Nico,

before I start, thanks for the great code examples to
play with.

The problem is, as you pointed out, that the buggy
class loader does
not delegate the loading of system classes (java.*) to
the system
class loader.

There is no way in the java language to mandate that a
subclass of
ClassLoader has to use the system class loader for its
job. But the
API description in Java Class Libraries Second Edition
Volume
1 indicates that loadClass "must ensure that it is
able to load all
classes referenced directly or indirectly by the
classes that it
loads". They give a specific example
"java.lang.Object" and say that
loadClass "might use findSystemClass()" to do the job.

In Java 1.2, class loading mechanisms changed a bit,
so in Java Class
Libraries Second Edition Volume 1 Supplement for Java
1.2 you are no
longer encouraged to overwrite loadClass. Instead, you
are supposed to
overwrite findClass, which in turn is called by
loadClass if loadClass
"cannot load the class from this class loader's
ancestors". You can
still overwrite loadClass, as it has not been declared
final,
unfortunately.

Where does kaffe fit in? Kaffe implements 1.1 class
loading semantics
according to Godmar. Some work for supporting 1.2
semantics has been
done already. I think that the model from 1.2 is
cleaner than the
model from 1.1, and I believe that kaffe will
eventually move to the
1.2 model.

What kaffe does: the processClass function asserts the
assumption that
a class is either the java.lang.Object class, or that
it has a
superclass. The test in fact assumes that the
java.lang.Object class
will be loaded only once (thus the pointer equality
test), and that is
violated by the test.

Is kaffe's behaviour a bug? That's a tricky question:
I am not
sure. According to the descriptions of class loader
semantics given
above, I believe that the buggy class loader's
behaviour is outside
the spec, for Java 1.2 semantics, and at least
questionable for 1.1
semantics. But kaffe fails with a not very useful
assertion message,
so that could be seen as a bug. Of course, you could
say that it works
on Sun and doesn't on kaffe, thus it's a bug in kaffe.
However that's
not a good idea, as Sun's implementation (generally
speaking) has its
own share of bugs, too.

How to fix it: Again, I'm not sure. We could print out
an
error message complaining that the ClassLoader is
operating outside of
the spec. We could try to relax assertions throughout,
by maintaining
a separate ObjectClass for every class loader.

I'm posting this to the mailing list, too, to get
further comments.

best regards,

dalibor topic


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com