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