Virtual extension methods -- a strawman design

[Brian Goetz]

> 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 goal was not to provide "method implementation by reference", though that 
may be an unintended consequence.  The intent was to move as little as 
possible from the spirit of interfaces while busting the choking restriction 
of "once you publish an interface, it is forever."

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

Probably so.  The intent of compiler weaving (in addition to VM weaving) was 
to minimize the impact on the tools ecosystem (e.g., static code analyzers, 
IDEs, AOP tools, etc) in that classes implementing an extended interface that 
have been compiled with a current compiler will look to tools as complete 
implementations of the interface.  Would be nice if this didn't create a huge 
ripple effect through the tools ecosystem; not only would that be mean to our 
friends, but it would delay adoption.

> 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).

I will explore this as an option, it seems worth considering.

> 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.

Here's my rationale: adding closures to the language without closure-izing the 
libraries will be unsatisfying for the users.  Without a means of interface 
evolution, we cannot closure-ize the libraries.  We explored static extension 
methods, but they are pretty unsatisfying; it is impossible for an 
implementation to provide a better implementation.  If its true that "today's 
problems come from yesterday's solutions", static extension methods feel to me 
like tomorrow's yesterday's problematic solution (parse that if you can!)