Final defenders

[Rémi Forax]

On 08/08/2012 01:07 AM, Stephen Colebourne wrote:
> On 7 August 2012 19:58, Sergey Kuksenko <sergey.kuksenko at oracle.com> wrote:
>> I think we get a conflict between what we declare and what we do. We are
>> declaring that defender methods is the feature  for interface evolution.
>> That means "defender methods shouldn't be used in a new interfaces
>> designed by right way". From the other side - lambdas may be fitted only
>> into interfaces - and we are using defender methods to provide required
>> functionality for bulk operations. But it is not interface evolution!
>> Let's be honest - defender methods have wider applicability than
>> interface evolution because of we do that.
>> Unfortunately I see only two consistent ways:
>> 1. Leave defender methods as interface evolutions way - in that case
>> functional interfaces is not enough - we need a way to use SAM abstract
>> classes as lambda target.
>> 2. Say: defender methods is own feature - and check what should be added
>> here in order to get really useful feature avoiding misdesign.
> I've been arguing this for some time. "Defender methods" are actually
> as important, if not more important, to the future of Java if done
> properly. The arguments in favour of limited change (default methods
> only, extra keywords, special cases) seem to be driven by a fear of
> changing the meaning of interfaces.
>
> I want to see the change embraced and seen as a first class citizen
> (even if that means pushing back the JDK 8 timescale). Traits are what
> this is all about, and doing it properly will pay huge dividends to
> Java over the next 5 years. Not being able to have a package scoped
> method on an interface, or a protected one will just feel wrong.

 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.
The default methods help to provide an always coherent implementation 
for class that implement this interface.

>
> My view is that we need to add the "package" keyword scope modifier (a
> good change in general), change coding standards to always include the
> the scope modifier (deprecate the use of default scopes for methods
> and variables), and only allow default methods on default interfaces,
> like abstract methods have to be on abstract classes. These changes
> provide the bedrock on which default interfaces can have a different
> set of rules to interfaces, ie. the rules of traits.
>
> Stephen
>

Rémi