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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
