final extension methods

[Lukas Eder]

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