Formal model for defender method resolution

David Holmes David.Holmes at
Tue Feb 1 02:11:56 PST 2011

Stephen Colebourne said the following on 02/01/11 19:58:
> On 1 February 2011 08:05, Peter Levart <peter.levart at> wrote:
>> So what we have here is two distinct desirable semantics for an interface method that overrides a method in a superinterface:
>> a) re-abstraction (that discards any default definition in a supertype)
>> b) re-declaration (that inherits any default definition from a supertype)
>> These two semantics can both be supported, followed by two distinct syntaxes:
>> interface A {
>>  Object m() default Defaults.m;
>> }
>> interface B  extends A {
>>  Object m(); // re-abstraction
>> }
> While a rare case, I do think the re-abstraction case is worth
> supporting if at all possible.
>> interface C extends A {
>>  Object m() default; // re-declaration which inherits default from A
>> }
> Or be more explicit - use a reference to a super-interface as the
> default. Its eminently readable and understandable:
> interface C extends A {
>  Object m() default A.m();
> }

I'm wondering about the semantics of this. Does it mean "look up A's 
default for m() at compile-time and mark my default as Defaults.m()"; or 
does it mean "mark my default as the same as A.m() and at runtime go 
look that up" ?

What I like about Peter's suggestion of just using "default" is that it 
implies exactly the same semantics as the current proposal to always 
inherit - hence we know it is implementable within the current proposal. 
Though it too can have different semantics:
- find the first default implementation in my inheritance hierarchy
- use the same as my immediate ancestor

and those two are quite different. I think I prefer the latter but I can 
see arguments for and against each.

David Holmes

More information about the lambda-dev mailing list