If you try running $JAVA at.dms.kjc.CSourceClass afterwards, you will see that kaffe thinks that it has detected a ClassCircularityError.
Now comes the confusing part, since I'll try to explain what I think is going on here ;)
First of all, CSourceClass is derived from CClass, which is derived from CMember (all in package at.dms.kjc). So when kaffe has to load CSourceClass, that will trigger loading CClass and loading CClass in turn will trigger loading CMember. This will cause kaffe to process CMember to state CSTATE_LINKED, while CSourceClass and CClass are both in the CSTATE_LOADED_SUPER state (and their classMappingState is NMS_LOADING).
Processing CMember to CSTATE_LINKED however, includes verifcation of the class CMember (both, verify2 and verify3). But in order to do this, the verifier has to resolve the types CSourceClass and CClass (they are needed for type checking during verification of the getAccessorOwner method). Since the verifier uses loadClass() to resolve the type, the ClassCircularityError is thrown (because classMappingSearch detects that the state is NMS_LOADING and that the current thread is responsible for it).
This seems to be a similar chicken-and-egg type of problem one's facing during class loading. That seems to have been solved by introducing some new CSTATES, like CSTATE_DOING_something and NMS states like NMS_*ING. Would a similar solution be appropriate for this problem?
cheers, dalibor topic
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
