Final defenders

Deepak S Patwardhan deepak.patwardhan at
Wed Aug 8 00:04:36 PDT 2012


I think default methods serve two purposes

1. Adding new methods without syntactically breaking code. (Hopefully, they
will not break code semantically, example, the default doesn't throw
unsupported exception)
2. Add new functionality, but it is not recommended that implementations
should override the new functionality. Example, I don't think it will be
recommended that apache collections or google collections implement map,
filter (right ?)

I think the idea of final defender comes from 2. So, how about going for
some new annotations ?

@DontOverride - means treat this as effectively final. Compiler will emit
warning (not error) if it finds such a default method being implemented in a
@DoOverride - means this is temporary, to give time to implementations to be
updated. The default could be removed in a future version of the interface.
Compiler will emit warning if it finds such a default method not being
implemented in a class.

We could use @SupressWarnings or a new annotation @SafeOverride (on the
implementing class) to suppress these warnings.

While we are on the subject of annotations, why not replace the default
keyword with java.lang.Default annotation ? 

public void m( ) throws Exception {...}

Looks better than, IMO,

public void m( ) throws Exception default {...}

In this case, we may just have a field in the annotation, shouldOverride
which could capture the idea of @DoOverride and @DontOverride

Deepak S Patwardhan.

-----Original Message-----
From: lambda-dev-bounces at
[mailto:lambda-dev-bounces at] On Behalf Of Paul Benedict
Sent: 08 August 2012 06:08
To: Rémi Forax
Cc: lambda-dev at
Subject: Re: Final defenders

On Tue, Aug 7, 2012 at 7:00 PM, Rémi Forax <forax at> wrote:
>  From a design point of view, I feel this is wrong because the traits 
> will expose its implementation and it's better to let the concrete 
> class that implements the interface at the end to decide how a concept 
> should be implemented.
> An interface with default methods is a way to expose a set of abstract 
> method plus some default methods implementing the default behavior.
> By example, Map.Entry, is conceptually a pair of value, the default 
> methods should provide a useful toString()/hashCode and equals to 
> avoid people that implement it to forget that this interface also 
> requires a contract on object methods.

Except it is now illegal to have override-equivalents of any
java.lang.Object method.

More information about the lambda-dev mailing list