OK, I'm yelling :) Please don't use Mark's patch!
It "fixes" it by stopping resolution finding the method on Object. However, it is legal to have an invokeinterface on an Object method
(as all interfaces subclass Object).
Instead, please use the attached patch to the interpreter. This converts an invokeinterface on an Object method into an invokevirtual (which is what 1.4 javac does anyway, but not jikes or 1.3 javac).
The JVMS is clear that invokeinterface is only to be used on interface methods. JLS 13.1 also states that a method call of something that (also) exists in Object is converted into a method call directly on Object if and only if the method was not redeclared along the type hierarchy of the type of the method call's qualifying expression. All versions of javac to date are buggy in some regard on this matter, but the latest jikes is emitting correct code. So, a correct compiler produces:
class A {
public String toString() { return ""; }
}
interface B {
int hashCode();
}
class C extends A implements B {
public boolean equals(Object o) { return false; }
{
toString(); // invokevirtual C.toString; javac 1.3 is wrong
((A) this).toString(); // invokevirtual A.toString
((B) this).toString(); // invokevirtual Object.toString
hashCode(); // invokevirtual Object.hashCode
((A) this).hashCode(); // invokevirtual Object.hashCode
((B) this).hashCode(); // invokeinterface B.hashCode; javac 1.4 is wrong
equals(null); // invokevirtual C.equals
((A) this).equals(null); // invokevirtual Object.equals
((B) this).equals(null); // invokevirtual Object.equals
}
}-- Someday, I might put a cute statement here.
Eric Blake [EMAIL PROTECTED]
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
