Groovy, Java 8 & Virtual Extension MethodsAs some of my daily projects deal with Java, I thought it would be a good idea to dig into some language changes Java 8 will provide. Undoubtedly, Java 8 is well known for introducing Lambda expressions as first-class language constructs. There will be a separate blog post concerning Lambda expressions, however there are certain not so well known ingredients Java needs to provide to do a soft migration to enhance already existing classes with lambda support.
Groovy: DGMThe Groovy programming language already comes with a rather advanced version of Lambda: Groovy closures. Apart from feeling like Lambda expressions, they additionally provide features to modify method delegation. This functionality has to be provided in order to allow the creation of lean DSLs, it is a key-feature for creating Groovy-based domain-specific languages. One advantage of closures being first-class language citizens is their applicability in collection classes. This is by far not the only use-case, but its one that hits core-API developers right in their face: how to modify already existing interfaces and classes without breaking already existing byte-code? Groovy did the trick by introducing the so-called "Default Groovy Methods". This term refers to a special set of static methods indirectly extending core Java classes such as java.lang.Object  by the all-known each method taking a groovy.lang.Closure has the first parameter. Another term for this kind of methods is static extension methods (see C# 4.0 ). But what happens when the compiler discovers a DGM method call? Whenever there is a tuple (instance, methodName, arguments) it will be executed against the static method DefaultGroovyMethods#
Virtual Extension MethodsTo support Lambda in already existing classes without breaking existing binary code, a new language feature has been introduced in Java 8: virtual extension methods  . Let's start with Java interfaces. According to the Java language specification an interface is
[An interface declaration] introduces a new reference type whose members are classes, interfaces, constants, and abstract methods. This type has no implementation, but otherwise unrelated classes can implement it by providing implementations for its abstract methods.However, with virtual extension methods, interface method declarations can specify default method implementations and therefore become so-called extended interfaces with one or more "virtual" extension methods. The term "virtual" might be confusing for those who are not quite familiar with JVM internals or the Java language specification. It refers to the terminated method invocation method during compilation. Non-private and non-super instance methods are said to be virtually invoked. Let's have a look at our first virtual extension method: The syntax for specifying a default implementation is to use the default keyword followed by a code block. This choice has been made against inline method declarations to outpoint the difference between method declarations in interfaces and classes. As the interface method provides a default implementation, applying the abstract keyword on such methods is not allowed. As a matter of fact, extended interfaces come closer to "traits" or "mixins" as found in other programming languages or abstract classes in Java. Compared to abstract classes, extended interfaces allow multiple inheritance. Brian Goetz is keen to mention virtual extension methods being more a tool for library developers to offer smooth API evolution keeping binary-compatibility with previous API versions than being used as "traits" or "mixins". Let's have a look at the classic diamond inheritance problem: This example does not compile as the compiler detects two candidates for potential method invocation. What if C would be an interface, how could we redefine #m() to call the virtual extension method of B#m()? Super method implementations can be invoked with <Interface-Name>.super.<Method-Name>. This doesn't solely work for interfaces, but also concrete and abstract classes. Another way of effecting the method dispatch is to remove the inherited default implementation.