Re: gcj is not type-safe

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:

Gary> I looked through libgcj and it seems that partial support for this is
Gary> already in place.  There's a function, _Jv_RegisterInitiatingLoader,
Gary> which gets called from all manner of places, but what it is doing is
Gary> maintaining within each classloader a list of classes that that
Gary> classloader is the defining classloader for.

Gary>  * Removed loadedClasses map from ClassLoader. It's now the VM's
Gary>    responsibility to manage the list of defined and loaded classes
Gary>    for each class loader.  (September 6, 2005)

There's a bit of confusion here in the code.

We have our own ClassLoader, which diverged from Classpath's some time
ago.  We kept the loadedClasses map in our copy.

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... :)

Gary> One possible fix would be to fix _Jv_RegisterInitiatingLoader to
Gary> actually register initiating loaders (as opposed to defining loaders)
Gary> and make it perform the check, but the number of different places
Gary> that _Jv_RegisterInitiatingLoader is called from makes me uneasy
Gary> about this: ideally I'd like to find one single place I could put
Gary> these checks. It's a pain that no method in java.lang.ClassLoader
Gary> is declared as final because you can't just put the checks in that
Gary> method and rely on the fact than no subclass can override it.  I
Gary> guess the constructor for java.lang.Class would be another place
Gary> I could look.

Yeah, putting the check in _Jv_RegisterInitiatingLoader seems wrong.

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.

Tom