Virtual extension methods -- a strawman design

Neal Gafter neal at
Tue May 25 14:29:11 PDT 2010

On Tue, May 25, 2010 at 11:35 AM, Peter Levart <peter.levart at>wrote:

> On Monday 24 May 2010 07:01:58 am Neal Gafter wrote:
> > Both default behaviors can be improved by recognizing that these
> > different methods don't have to resolve to the same implementation:
> >
> > If both interface A and interface B declare defender methods with the
> > same signature, there is no ambiguity in a class C that extends A and
> > B.  Invoking the method through C is a compile-time error (ambiguous),
> > invoking through A gets A's behavior, and invoking through B gets B's
> > behavior.  There is no need to guess how rare these cases might be.
> >
> How could this be achieved without modifying the specification of the JVM?

Adding extension methods as contemplated requires changing the JVM

> How could C provide distinct implementations of a method with the same name
> and parameter types
> that would be selected in response to invoking them via interface A or B?

Doing that would require additional language support.  If it is deemed worth
doing there is an obvious syntax to use.

> Is it possible for
> code emited by javac in the single method body to find out via which
> invokeinterface method it
> was actually invoked and dispatch accordingly?

I don't propose such a thing.

More information about the lambda-dev mailing list