Virtual extension methods -- a strawman design

Neal Gafter neal at
Sun May 23 22:01:58 PDT 2010

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.

On Sun, May 23, 2010 at 5:52 PM, Howard Lovatt <howard.lovatt at> wrote:
> Alex Blewitt said:
>> This is the classic 'diamond problem' that is experienced with multiple implementation inheritance.
>> Unfortunately, the proposal document (
>> 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.

More information about the lambda-dev mailing list