Final defenders

[Howard Lovatt]

I am very much for making defender methods a proper feature, i.e. morphing
interfaces into full blown traits that will eventually replace abstract
classes in most use cases. But this can be done slowly as long as we think
ahead. I would rather not push back JDK8 since I already find the release
cycle too slow. How about, for 8 having defender methods that have normal
syntax; no keyword at all, i.e. void foo() { ... }. Then in the future
private, protected, and package access can be added.

An aside re. classes: It is a pity that the default for a class member is
package and not public, but that can't be fixed (at least without
introducing a source version number statement). We already live with the
default access in an interface, public, being different from a class,
protected. It could be made a little better by allowing package to be
explicitly stated for class members and the compiler could issue a warning
for a missing protected inside a class (but not for a missing public in an
interface).

On 8 August 2012 09:07, Stephen Colebourne <scolebourne at joda.org> 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.
>
> 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
>
>


-- 
  -- Howard.