Formal model for defender method resolution

[Neal Gafter]

On Fri, Feb 18, 2011 at 2:52 PM, Dan Smith <daniel.smith at oracle.com> wrote:

> On Feb 2, 2011, at 9:56 PM, Neal Gafter wrote:
>
> > On Wed, Feb 2, 2011 at 12:57 AM, Peter Levart <peter.levart at marand.si
> >wrote:
> >
> >> On 02/02/11, David Holmes wrote:
> >>> Neal Gafter said the following on 02/02/11 16:30:
> >>>> For the specific case of
> >>>>
> >>>>   intf A { String m() default X.a }
> >>>>   intf B { String m() default X.b }
> >>>>   intf C extends A { String m() default none }
> >>>>   intf D extends A, B, C { }
> >>>>
> >>>> A class that implements D has a single, unique, non-overridden
> >>>> implementation for the method family (B.m), and it is a suitable
> >>>> implementation (i.e. the return type works) for the inherited abstract
> >>>> method.  So there doesn't appear to be any problem with that class,
> and
> >>>> therefore there should be no problem with these interfaces
> >>
> >> Does anything in existing Java method resolution rules express that a
> >> "redundant" interface inheritance graph should be pruned in any way?
> >>
> >
> > How would you be able to tell?
> ...
>   void m1(K1 k1, K2 k2, K3 k3) {
>    LinkedList l1 = k1.foo(); // javac: ambiguous; Eclipse: ok
>    LinkedList l2 = k2.foo(); // javac: ok; Eclipse: ok
>    LinkedList l3 = k3.foo(); // javac: ok; Eclipse: ok
>  }
>

No matter which compiler is right, it appears your test confirms that the
redundant inheritance in case 2 behaves the same as the non-redundant
inheritance in case 3.  case 1 is an inheritance graph of an unrelated
shape.

...I also tried this:
>
> ...
>  void m2(N1 n1, N2 n2, N3 n3) {
>    n1.foo(); // javac: CNFE; Eclipse: CNFE
>    n2.foo(); // javac: CNFE; Eclipse: CNFE
>    n3.foo(); // javac: CNFE; Eclipse: CNFE
>  }
>

Again, your test appears to confirm that a redundant interface inheritance
does not change the behavior.

Cheers,
Neal