final extension methods

[Lukas Eder]

> First of all, default methods don't count against the limit of one abstract
> method for being considered functional interfaces.  So the advantage you
> list second is already there, final or not.  See, for example, the and() and
> or() methods on Predicate in the lambda builds.

Very nice, I wasn't aware of this. But of course, it makes sense.

> The other part is how far we're going to go to support class-building tools
> in interfaces, such as final methods, private methods, protected methods,
> static methods, etc.  The answer is: we don't know yet, but we're not in a
> hurry to add things now "just because they seem useful" that we can just as
> easily add later.  So for now, none of these things are in.  But we
> recognize that as people start to use interfaces more like classes, more of
> the tools for building classes may become desirable.

You're right. These things could easily be added later, too, e.g. in
Java 9. On the other hand, this reminds me of the @Override
annotation, which has seen a slight enhancement in Java 6, allowing
for it to annotate also "implementing" methods, not only "overriding"
methods. This change has been a bit of a compatibility problem between
those Java versions in the past. At least for me. Adding support for
class-building tools only later might result in similar issues. But I
agree that these issues are not the most important ones.

Cheers
Lukas