SAMbdas in Java

Since the initial Lambda proposal was released (and the in-depth InfoQ analysis), there has been a subsequent state of the lambda which has significantly moved the goalposts of the lambda project in JDK 7.

There were a number of criticisms of the initial syntax proposed, but the problems ran deeper than pure syntax (which after all, was just a strawman). One of the key issues was that Java has no direct support for function types; and that introduced holes in Java's type system (an array of functions would permit exceptions to leak). Whether these problems were insurmountable or not (or more likely, within the given time-frame for JDK 7's increasingly delayed release), the current state-of-the-lambda has no mention of function types at all.

Instead, we have an adaptation to make it easier to write inner classes. These classes are referred to as SAM classes, or Single Abstract Method classes. This represents a significant subset of abstract classes and interfaces in the Java language that just have a single abstract method; for example, Runnable's run() method, Comparator's compare() method, and so on. (Abstract classes which have a single abstract method are also permitted such as Eclipse's org.eclipse.core.runtime.jobs.Job.)

The current work-in-progress spec suggests that the following would therefore be equivalent:

Collections.sort(list,new Comparator() {
  public int compare(Object o1, Object o2) {
    return(o1.toString().length() - o2.toString().length());
  }
}
// is the same as
Collections.sort(list,
  { Object o1, Object o2 -> o1.toString().length() - o2.toString().length() }
);

Again, the syntax is at the proposal stage so may change in the future, but the idea is that the lambda project will permit inner classes to be written more succinctly than using the new anonymous class approach. Otherwise, the lambdas remain the same expressiveness as inner classes; you can capture state from the local heap (though whether that heap remains mutable post capture is still a hotly debated topic). However, some changes to the language (like being able to capture effectively final variables), and having type and method/exception inference makes it much more concise than the equivalent anonymous class.

One reason for following this approach is to permit existing classes (primarily the java.util collections classes) without having to be modified. Had the function type approach been used, then it would have been necessary to retro-fit the collections classes to take lambdas as well, or forgo their inclusion (and therefore usage) in JDK 7. Whilst other libraries would have been able to be flexible, the monolithic Java libraries aren't so mutable and this may be a reason why a different approach was chosen.

It may also be possible to use method references to substitute for a SAMbda as well. For example, we could have:

public class Comparisons {
  public static int compareLength(Object o1, Object o2) {
    return(o1.toString().length() - o2.toString().length());
  }
  public static int compareHash(Object o1, Object o2) {
    return(o1.hashCode() - o2.hashCode());
  }
}
// examples
Collections.sort(list,#Comparisons.compareLength);
Collections.sort(list,#Comparisons.compareHash);

The # references are method handles, which are similar to java.lang.reflect.Method. However, unlike Method, they are resolved at compile-time (rather than run-time) and the JVM's JIT will have sufficient smarts to be able to in-line the method references automatically. There are also other optimisations that this permits, such as creating a single class to represent delegated method handles for a given SAM type, rather than creating a new anonymous class at the point of use.

Finally, there are contentious issues as well. The initial draft of the current spec prohibited the use of break and continue, but that was subsequently clarified to prevent breaking out of a SAMBda into the enclosing scope. The other key change is that return is implied, and is not allowed in the body of the lambda itself; though a substitute keyword yield (not to be confused with Thread.yield()) has exactly the same semantics as a return would in an inner class. Ostensibly this is to permit a lambda to trigger a return from a method in which it is called later (a so-called 'long return'). There may be a change in the syntax in the future to permit return to be used unadorned in a lambda, and require a subsequent new keyword (or keyword combination, like long return). Other similarities will include this to refer to the enclosing SAM instance, and Outer.this to refer to an instance of the enclosing class.

The changes to the lambda proposal to be a drop-in replacement for SAMs is less ambitious than the project's original proposal, but has the advantage of being easier to implement and not requiring any changes to the existing collections classes in order to be immediately useful. (Changes to the collections classes would have been necessary if function types were added in any case.) It may also be possible to create function references in the future using the same lambda-like syntax, but targeted for a future JDK release.

This post has been updated to reflect the fact that the break/continue has been resolved, and to include the type inference for formal parameters and exception types.