Java 8 virtual extension methods

Posted on by lukaseder
I’ve been following the evolution of the Java 8 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 it was 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. See the full mail and follow-up on the lambda-dev mailing list here: http://mail.openjdk.java.net/pipermail/lambda-dev/2011-December/004426.html

Published by lukaseder

I made jOOQ

9 thoughts on “Java 8 virtual extension methods”

    1. Yes that’s what many people noticed, even if the concept of extension methods was actually borrowed from C#. In any case, we’re going to learn Java afresh… :)

      Reply

  2. I know this is an old post, but it shows up when googling for Java 8 features. So here’s a remark: default methods in Java 8 [1] are not extension methods in the sense of C# [2].

    The point of an extension method is that it allows you adding members (syntactically) to an existing class without touching it (or its superclasses / interfaces). You can, for example, add a method to String.

    Default methods in Java 8 are non-abstract methods in interfaces that are added to classes extending the interface. To add a method to an existing class, you need to modify an interface it implements. In more recent documents, Oracle does not use the (confusing) term “virtual extension method” anymore it seems [3]. Default methods are some form of mixin [4].

    [1] http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
    [2] http://msdn.microsoft.com/en-us//library/bb383977.aspx
    [3] http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
    [4] http://en.wikipedia.org/wiki/Mixin, http://programmers.stackexchange.com/questions/218903/are-interfaces-with-java-8-virtual-extension-methods-the-same-thing-as-mixins

    Reply

    1. Yes, there had been many names to what is now called “default methods”. At the time, an official presentation given by Brian Goetz at Devoxx (linked from this article) referred to them as “virtual extension method” [sic], later on, they were called “defender methods” before moving on to “default methods”, so from a historical perspective, I think it is OK to leave the article as it is now.

      Btw, I agree with your assessment, and I think it had also been brought up on lambda-dev at some point, which eventually led to the current name. I personally find the current name misleading. It originates from the times when the expert group wanted to avoid creating something like Scala traits in Java, when in fact, they did. Also, the “default” keyword was a bad choice making the language as irregular as it has always been. It would have been nice to move forward and make classes and interfaces more similar by allowing methods to be abstract (through a “;”) or concrete (through a body). No “default” keyword is really needed.

      But oh well :-)

      Reply

Leave a Reply