Default methods syntax/semantics [Re: Updated State of the Lambda]

Brian Goetz brian.goetz at
Mon Dec 12 15:43:14 PST 2011

> On the first point - the need for default with a method body, Remi
> makes the case for using it to imply that the superclass version takes
> precedence over the interface one - "You need default because you need
> to express the fact that a method defined in a super-class will always
> win to one defined in an interface."
> I'm afraid I simply don't think thats necessary. Bear in mind that in
> the past I've suggested adding syntax to clarify meaning (like the #
> in lambdas to indicate capture of the return keyword), so its
> interesting in its own right that I think less is more here.

This point has been raised before and discussed extensively.  We're 
pretty comfortable with the degree of "noise" that it introduces, and 
prefer it this way.  Note that this "noise" only impacts the library 
developer, not the user.  (Interfaces are consumed far less often than 
they are written.)  It is a small cost for clarity.

> Having said all that, perhaps examining the "default none" case in
> isolation may miss something. For example, here is an interesting
> alternative approach to the whole area - requiring defaulting
> interfaces to declare themselves as such, similar to the way abstract
> classes have to:
> interface A {
>    void a();  // normal interface, no defaulting allowed
> }
> default interface B {
>    void a();  // normal interface method
>    void b() { ... }  // interface method with default body
> }
> default interface C extends B {
>    void a();  // reabstraction
>    void b() { B.super.b() }  // override for documentation, as per classes
>    void c();  // normal interface method (same syntax as reabstraction)
> }

Which means that adding "default" to an interface is not a binary 
compatible change, since it changes the meaning of declarations like 
a().  I don't think that flies.

Compatibility under separate compilation is the real challenge in this 
space.  If you approach it with the perspective that the entire 
hierarchy is somehow an atomic unit, you've already lost.

More information about the lambda-dev mailing list