Virtual extension methods -- a strawman design

[Howard Lovatt]

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.