Eric Blake wrote:
> The compiler must always allow you to invoke a
> public method from Object from a qualifying type of an
> interface (since in JLS 9, interfaces implicitly have all
> public methods from Object), but the compiler's responsibility
> according to JLS 13.1 is to flatten that to a call on Object
> if and only if the qualifying type does not redeclare
> (or inherit a redeclaration) of the method.
I can see where you're coming from, as a compiler writer, but from my
point of view (as a VM builder) this requirement is totally meaningless,
because in the face of class file version the interface can change
anyway.
> Corallary - since no interface can redeclare a final method,
> a compiler should never produce invokeinterface
> SomeInterface.getClass or any of the other final methods in
> Object;
I agree, but from of VM point of view, it really doesn't matter, it
isn't any different from:
class base {
public final void run() {}
}
class test extends base implements Runnable { }
> However, there are buggy compilers out there that emit
> invokeinterface Runnable.toString(), even though Runnable
> does not redeclare toString; and a robust JVM implementation
> will be prepared to deal with this situation.
Like I said above, even without a broken compiler you can still
encounter this by removing the method from the interface after the
caller has been compiled.
> This is a binary compatibility issue - in other words, it is
> possible to expose javac 1.4's bug by using inconsistent .class
> files to show whether a class was compiled with a call
> invokevirtual Object.toString or invokeinterface
> SomeInterface.toString (and the jacks compiler test suite does
> this).
I don't understand what you mean here, could be please elaborate?
Regards,
Jeroen
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
