Final defenders

[Stephen Colebourne]

On 8 August 2012 08:28, "Zdeněk Troníček" <tronicek at fit.cvut.cz> wrote:
> Stephen Colebourne napsal(a):
>> 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.
>
> In other words, you propose to change one of the Java corner stones
> (interfaces). This is not evolution, this is revolution.

Today, Java has three features - classes, abstract classes and
interfaces. I'm suggesting that a fourth is added - default interfaces
(aka traits). Does this change the meaning of interfaces, or add to
the meaning? My view is that it is additive and not threatening (not
that I think well-designed change is threatening anyway).

> Could you elaborate on why are defender methods, in shape you are arguing
> for, so important for the future?

As my coding life has proceeded I find I want multiple inheritence
more and more. This may simply be a fact of any codebase that grows
over time, or it may be a result of being able to picture more
advanced designs than 10 years ago.

Where there is no doubt in my mind is that I will use traits (in
whatever form they are provided) for far, far more than interface
evolution when JDK8 is released.

Interface evolution is a primary concern of Sun/Oracle and those that
produce codebases where published interfaces can never change. The
world I have primarily worked in (and where I suspect the majority of
developers work) is one where interfaces can be changed, thus the
"interface evolution" argument is not especially relevent.

>> 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.
>
> Could you give any examples of those "huge dividends"? Could you show when
> protected methods in interfaces are useful?
> I have already asked for examples of protected interface methods in this
> conference and did not get any.

JSR-310 has an example, where we have to use a "do" naming prefix
together with lots of Javadoc for methods that should be protected on
an interface:
https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/calendrical/DateTimeField.java#L131

If you look further up that same class you'll see the compare method
is marked as one that should be a default method.

This is an interface because it is implemented by enums. So, proper
traits functionality would solve much of another requested feature -
"abstract enums".

By not adding protected/private/package methods from the start of this
feature, we are going to end up with design mess-ups like the "do"
naming prefix in JSR-310, simply to get around an inadequate feature.

A second case is where I want an interface that is limited in scope to
a package. While the interface can be declared package-scoped, all the
methods are still public in scope. This causes the implementations to
have to declare their methods public, which nullifies the usefulness
of the design.

I stress again therefore that traits, in whatever form they appear,
will be widely used by API designers and will radically change the
feel of many APIs at the gross design level, perhaps much more than
lambdas will. (Lambdas will have more of an impact on the detailed
design of individual methods)

> Each programming language is based on some principals. Any change of these
> principals probably means discontinuity and even if the changes are done
> in backward compatible way, they probably break the language integrity.
> I remember the times when Java students asked "why Java does not allow to
> overload operators?". "It is so useful in C++!".
> (Or more funny: "How do you multiply matrices in Java if you cannot
> overload the operator *?")
> Some features seem to be useful at the first sight but their real value is
> questionable. And I am quite convinced that if we were in 1999, some
> people would argue for operator overloading which is useful only when you
> want to make the code less readable.

Java does not override == to ,equals() or < to compareTo(). These
changes would dramatically enhance the readability of code, and its
noticable that the vast majority of lambda examples at conferences use
primitives to avoid the problem of Java's verbosity within lambdas.

Doing traits properly is not a threat to Java, nor does it break the
language principals. Adding lambdas will already cause developers to
re-evaluate the best design for any given situation in exactly the
same way that Java5 did, and as such will cause JDK8 to effectvely
fork Java in the same way that Java 5 did (IBM took years to adapt to
Java 5, many open source projects still haven't).

On 8 August 2012 10:32, David Holmes <david.holmes at oracle.com> wrote:
> I think this just highlights that default methods are not intended to be
> what you are trying to make them. They exist to provide an
> implementation where none would otherwise exist, not to be an enforced
> and non-overridable implementation. They might look like traits from a
> certain angle but they are at best a very limited form.

Respectfully, I'd ask you to take a step back and stop thinking of
interface evolution as a problem caused by the lambda god, a problem
that default methods solve. Instead look at traits as a true feature
to be grasped with both hands, one that happens to help lambda into
the language. I, for one, will be using default methods as traits in
whatever form they are added, and I'd prefer that form to be the best
possible.

Stephen