OpenOffice and gcj at runtime
Tue Dec 14 22:52:00 GMT 2004
>>>>> "Bryce" == Bryce McKinlay <email@example.com> writes:
Bryce> Yes, I agree it should go in - just want to stress that this is a
Bryce> work-around and it should really be fixed properly once we move out of
Bryce> freeze. Abstract and interface methods "shouldn't" ever have a -1
Bryce> dispatch index.
With Caolan's test case, on the trunk, I don't see a -1 index.
The basic problem is that there's no way to know whether we want
"invokevirtual" or "invokeinterface" semantics given just an object
and a jmethodID, since the jmethodID doesn't include information about
its declaring class.
So when we get to the call that hangs, we see that the method index is
"1". But this points to some other method in the vtable -- since in
this case the index is really an interface table index, not a vtable
I agree that this fix is just a band-aid for 4.0.
Retro-fitting the declaring class into the jmethodID is somewhat ugly,
since it means more memory use (another pointer per method) just for
this one obscure case.
Perhaps the -1 index problem occurs in 3.4. I didn't look at this.
But, that is what Andrew's first patch fixes.
More information about the Java