Virtual extension methods -- a strawman design

[Neal Gafter]

Brian-

There are two separable language proposals embedded here.  The first is the
ability to put default method implementations into an interface.  The second
is the ability to provide a method implementation by reference to another
method.  It isn't clear why one would intertwine the two proposals, and I
don't understand the motivation for the latter (I don't buy the conclusion
in the "Syntax Options" section).  I'm guessing it is in part to simplify
the implementation strategy, but that is a poor motivation.

The proposed behavior for old class files might as well be done for all
classes.  That improves binary compatibility.

Related to that, I'm concerned about your plan for handling ambiguities.  I
think there is a way that allows more interface evolutions without breaking
existing code.  The idea would be to have the VM always add the defender
methods to classes missing them (i.e. javac would not do it), and have javac
generate invokeinterface instructions for the invocations, rather than
invokevirtual.  Then the VM can match up the interface with its default
implementation, even though there might be a defender method with the same
signature in another interface.  At compile-time, if there are two concrete
methods in the candidate set (e.g. two defender methods), the invocation is
ambiguous (i.e. it reduces to an existing language rule).

My most important comment is this: the relationship between this proposal
and the (not well described) goals of project lambda are not clear.  What
software engineering techniques are you trying to enable, and for whom, and
how does this proposal improve things?  Without a clear explanation, this is
a solution in search of a problem.

Cheers,
Neal