Hi Graydon, Yes, you're right. The virtual method calls should do method lookup via the object type. This happens for all return types apart from void for some reason. The attached patch fixes this.
Thanks for finding this. It appears to fix the "offset" problem! Rob. On Sat, 08 Jan 2005 00:50:04 -0500, graydon hoare <[EMAIL PROTECTED]> wrote: > hi, > > I think I have isolated a bug in jamvm which causes subtle (but serious) > incorrect behavior on the GTK JNI code. the bug is that if P is a parent > class and C is a child class, then invoking a virtual method M on an > object of class C, from jamvm's JNI, invokes P.M() rather than C.M(). so > for example the event handlers on GtkGenericPeer are being fired when > events arrive on GTK frames, even though the speciailzed versions in > GtkFramePeer are supposed to be overriding. > > I've attached a reduced testcase, in the form of a tarball which > contains JNI and java sources, and a shell script which builds the > problem program and runs it. you'll have to edit the script to make it > work on your system, but it should be obvious. > > I have not been able to immediately see which part of jamvm causes the > fault. I'll continue to look through the sources for it on monday. > > -graydon > > >
jni-patch
Description: Binary data
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
