RE: Eclipse 3.0

[Jeroen Frijters]

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