On Fri, 8 Aug 2003 10:22:58 -0600 (MDT) Timothy Stack <[EMAIL PROTECTED]> wrote:
Hi, > > An idea how to fix this? My guess would be to defer verification > > of the superclass until after the subclass is in state CSTATE_LOADED_SUPER > > (and NMS_LOADED). This could probably be done by creating a special > > getClass() that returns a class that is only CSTATE_PREPARED, > > I don't think this will work with user loaders since getClass() calls > loadClass(), which can call a user loader, which can do whatever it wants. Hmm. I thought that a user loader would either return whatever defineClass() returns (when loadClass is called with resolve==false) or what resolveClass() returns (when loadClass is called with resolve==true). Therefore, I thought that we could indeed predict what's returned by a user loader. So it seems I'm once again missing something? > > but not > > CSTATE_LINKED. The subclass would load the superclass using this special > > getClass(), set its own state to CSTATE_LOADED_SUPER (and NMS_LOADING) > > and process the superclass to CSTATE_LINKED afterwards. That way, the > > verifier would be able to properly resolve the subclass while verifying > > the superclass, but detection of ClassCircularityErrors should still > > work? > > I think the circularity checking is broken, its just checking to see if > there is a loop in calls to loadClass and not checking that its still > trying to load the super class. For example, in this case CMember would > have finished loading its super (java.lang.Object) so there is no > circularity. > > I'm thinking the fix would involve a new class state and classEntry state > that break up the loading of the super class. I'll try to look at it more > over the weekend... Sounds like you'll have a busy weekend, then ;) Greetings, Helmer _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe