Virtual extension methods -- a strawman design

[Peter Levart]

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? If C implements both A 
and B then it only contains a single instance method that @Override-s both methods in interfaces 
A and B at the same time. The invokeinterface bytecode dispatches to the same method 
implementation regardless of whether it was specified as A.method or B.method.

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

Regards, Peter


> On Sun, May 23, 2010 at 5:52 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> > Alex Blewitt said:
> >> This is the classic 'diamond problem' that is experienced with multiple
> >> implementation inheritance. Unfortunately, the proposal document
> >> (http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf) brushes this
> >> under the covers (5.1) with a 'should throw an exception' at this
> >> point. This is pretty silent, outside of any compiler warnings, and is
> >> definitely a change of behaviour.
> > 
> > Section 4.2 seems to cover what happens.
> > 
> > "4.2. Resolving ambiguity
> > If the class implements multiple extended interfaces, both of which
> > provide a default
> > implementation for the same method name and signature, the
> > implementing class MUST
> > provide an implementation.  (This is expected to be a quite unusual
> > case.)  The existence
> > of the InterfaceName.super.methodName() syntax makes it easy for the
> > class to choose
> > one of the defaults.  (We might choose to relax this restriction if
> > both interfaces provide the same default.)"
> > 
> > This solution is the normal solution for traits, i.e. programmer has
> > to resolve the issues.
> > 
> > Alex Blewitt said:
> >> public class A implements DataStructure {
> >>   public boolean filter(FilterSam filter) {...}
> >> }
> >> // Later, someone makes the change:
> >> public interface DataStructure {
> >>   extension DataStructure filter(FilterSam filter) default
> >> Default.filter; }
> > 
> > When A is net recompiled there is a compiler error. If A is not
> > recompiled there is a link error. See section:
> > 
> > "5.1. Resolving ambiguity
> > In the unlikely case that the VM attempts to load a class that
> > implements multiple
> > extended interfaces that have a common defender method but with
> > different defaults, the
> > VM should not attempt to resolve the ambiguity automatically.
> > Instead, it should
> > generate a bridge method that throws UOE or similar exception.  We
> > expect this situation
> > to be rare."
> > 
> > I would agree with the assessment that this will be rare and therefore
> > catching the error is sufficient.
> > 
> >  -- Howard.