Formal model for defender method resolution

David Holmes David.Holmes at
Wed Feb 2 14:47:33 PST 2011

Peter Levart said the following on 02/02/11 23:55:
> So when we are talking about method C.m() in:
> interface A { void m() default X.m; }
> interface C extends A { void m() default none; }
> then all the compiler can deduce from the source is that C.m() is
> abstract (as any concrete implementation of C must provide m's
> implementation). What can compiler say about the semantics of C.m?
> Nothing much besides that the author of C choose that the default
> implementation of A.m is perhaps often not suitable for implementors
> of C. The semantics of A.m and C.m are potentially conflicting, yes,
> but should compiler barf on that when both interfaces are used in
> implementation:
> class F implements A, C {}

Not in this case, because implementing C completely encompasses 
implementing A so the "A" is redundant. This is my preferred semantics 
for this. The problem arises when you then add

interface B extends A { void m() default X.b; }


class G implements B, C { // or A, B, C
   // what is G.m() ?

Now the compiler has a conflict between B's claim that m() should 
default to X.b, and C's claim that m() should be abstract. So the 
compiler should quite rightly reject G and force the programmer to 
resolve the conflict.

If we have:

interface D extends B, C { }

then I suggest, for simplicity and consistency that the compiler also 
reject this.


> Regards, Peter

More information about the lambda-dev mailing list