RFC: Non-indirect-dispatch and failed loading of classes

Andrew Haley aph@redhat.com
Thu Sep 8 13:35:00 GMT 2005


Ranjit Mathew writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Hi,
 > 
 >   Consider the following:
 > 
 > Foo.java:
 >   class Foo { }
 > 
 > Bar.java:
 >   class Bar extends Foo { }
 > 
 > Compile both to bytecode and then remove Foo.*. Now try to
 > compile Bar.class to object code (non-indirect-dispatch).
 > We get an internal error with current mainline.

We should get a class not found error.

 > In this change:
 > 
 > http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jcf-parse.c.diff?r1=1.158&r2=1.158.4.1
 > 
 > load_class() sets TYPE_DUMMY for a RECORD_TYPE if we failed to
 > load it, but that bit is effected only for non-indirect-dispatch.
 > 
 > Is there a reason we can't make this independent of indirect-dispatch?

Yes.  When not using indirect dispatch we verify classes at compile
time, and thus we really need to have them around.

Andrew.



More information about the Java mailing list