Re: Note on BC and type assertions

[Tom Tromey <tromey at redhat dot com>]

>> There is a hidden issue, which is what this code looks like.  E.g., if
>> it includes a call to Class.getModifiers (to check non-abstractness),
>> then it needs to go via the [ao]table. 

Andrew> I don't think that's possible: the assertions are checked very early.

Hmm, looks like we never actually call verify_class on the BC branch.
Whoops.  I put this on my to-do list.

We are sorely missing test cases, especially for verification failures
of various kinds.

>> If it is a new _Jv_ function, then that is another fixed part of
>> the API.  This isn't a major thing, of course, but I wanted to make
>> sure it is explicit.

Andrew> That's true, indeed: we might have to use class.forName() for
Andrew> backwards compatiblity.  

How will we call Class.forName() before linking?

Either we have to use the atable for all these calls (meaning, link
before verifying), or we have to use low-level libgcj APIs.  In the
latter case, we can't provide compatibility between newly compiled
code and old versions of libgcj, because we might have to add a new
function.

Tom