gcj is not type-safe

[Gary Benson]

Tom Tromey wrote:
> >>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:
> 
> Gary> I looked through libgcj and it seems that partial support
> Gary> for this is already in place.  There's a function,
> Gary> _Jv_RegisterInitiatingLoader, which gets called from all
> Gary> manner of places, but what it is doing is maintaining within
> Gary> each classloader a list of classes that that classloader is
> Gary> the defining classloader for.
> 
> I think _Jv_RegisterInitiatingLoader does register initiating
> loaders, however it records this in the loadedClasses map, which
> is also used to record defining loaders.  I'm not sure whether
> this is a real problem; I suppose at one point I thought it wasn't,
> but naturally I could have been confused, particularly since we
> don't check this constraint... :)

I'm not sure either.  It's difficult to _be_ sure, since _Jv_RIL is
called from so many places that it's not obvious that they all expect
to do the same thing.  There's also the issue that the _only_ thing
that _Jv_RegisterInitiatingLoader does is add the class to the
loader's loadedClasses map, and there's one case where classes are
added directly (in ClassLoader.defineClass(String, byte[], int, int,
ProtectionDomain)).  Call me chicken but I plan to avoid touching
_Jv_RegisterInitiatingLoader like the plague... :)

> I think the bug here is that we don't implement the method loading
> constraint mentioned in 5.4.2 (re-mentioned in 5.4.3.3):
> 
>    http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#71421
> 
> The reason I think this is that what happens here is that RT casts
> one kind of R into the other -- because the getR method returns one
> kind of R while RT directly references the other kind.  IOW, the
> return type of getR is not validated according to the above rule.
> 
> It turns out there's even a FIXME for this in
> _Jv_Linker::resolve_method_entry.  So I would suggest fixing it
> there.  We do implement this for fields, see
> _Jv_Linker::find_field_helper.

Yeah, that would work.  Out of interest I modified my testcase to use
a field rather than a method.  We catch it in find_field_helper, but
Sun Java catches it in exactly the same way as it catches the dodgy
method.  So the question is does the spec contain two ways to catch
this just in a belt-and-braces kind of way, or is it that there are
some things which slip past the method check and others which slip
past the initiating loader check?  I guess more investigation is
required...

Cheers,
Gary