Virtual extension methods -- second draft

[Neal Gafter]

On Tue, Jun 8, 2010 at 6:14 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> I've updated the draft on Defender Methods:
>   http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf

In section (3), method dispatch, it isn't clear if this is discussing
compile-time behavior or runtime behavior, nor is it clear is this is
describing the behavior when the qualifying type is a class or the
qualifying type is an interface.  The full matrix must be described.
To give an example of the kind of information missing in this section
as written, imagine an "invokevirtual" method invocation.  The
qualifying type in the bytecode is the static type of the receiver.
But this section says that it is resolved (at runtime?) based on the
type of the interface being searched.  The type of the interface,
however, isn't available at runtime because the JLS requires that the
constant pool entry for the invokevirtual instruction be given the
qualifying class type.

Taking the section more literally, it appears to be discussing runtime
dispatch of an invokeinterface invocation where the receiver type in
the constant pool is D.  But the section discusses walking up the
superclass hierarchy from D.  Since D is an interface, its direct
supertype is Object, and there are no intermediate supertypes.
Perhaps some of the mentions of "D" in this section should instead be
referring to the actual runtime class of the receiver.

In section (3.1), resolving ambiguity, this describes one kind of
failure at runtime.  Is there a corresponding compile-time error to
avoid these?  Section (11) says that conflicting methods in different
superinterfaces (same signature, different return type) are rejected
today.  I don't think this is correct.  Any conclusions based on that
premise are suspect.  What are the binary compatibility implications
of adding defender methods?  Section (13) seems to assume that the
previous API suite had no defender methods, but the binary
compatibility implications of adding defender methods when some may
already be present should be explained.

Nice work, by the way.