Final defenders

Stephen Colebourne scolebourne at joda.org
Tue Aug 7 16:07:00 PDT 2012


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.

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


More information about the lambda-dev mailing list