final extension methods

[Brian Goetz]

There's a few things tangled here.

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.

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.


On 12/18/2011 7:42 AM, Lukas Eder wrote:
> Hello,
>
> I've been following the evolution of the Lambda expressions project
> for a while now, and I'm really thrilled by its current state of
> progress. The latest "easy-to-understand" presentation I've found is
> this one:
> http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf
>
> Now, as an API designer, I'm particularly interested in the concept of
> virtual extension methods and I was wondering whether you also
> considered to introduce "final" extension methods as opposed to
> "default" ones. For example:
>
> interface A {
>    void a();
>    void b() default { System.out.println("b"); };
>    void c() final { System.out.println("c"); };
> }
>
> When implementing the above interface A, one...
> - MUST also implement a()
> - MAY implement / override b()
> - CANNOT override c()
>
> Advantages:
> - API designers can create convenience methods more easily without
> risking client code "illegally" overriding default implementations.
> That's one of the main purposes of "final".
> - Lambda expressions wouldn't need to be limited to pure "functional
> interfaces" (single-method interfaces), as a functional interface
> would still be "functional" if it also had any number of final
> extension methods. For example, the above interface A would become a
> functional interface, if b() was removed or if b() was made final as
> well.
> - Extension methods would have more features in common with regular
> methods, which can be final as well. I guess for the reflection API
> and for the JVM, that's a plus.
> - The JVM is modified anyway to support extension methods. Java 8's
> momentum could be used for this feature as well, i.e. now is the right
> time to think about this
>
> Disadvantages:
> - A class could inherit multiple colliding final method
> implementations in the case of "diamond interface inheritance". This
> could lead to new compilation errors in existing code. I guess this
> lack of backwards compatibility is the biggest drawback.
>
> As with multiple inheritance itself, careful API designers could
> further improve their API's when using final extension methods,
> whereas less careful API designers might break client code. But this
> is the case with previous usage of "final" as well, so I think final
> extension methods would be a very nice addition to Java 8.
>
> Cheers
> Lukas
>