AngelikaLanger.com - Effective Java - Java 8 - Lambda Expressions & Method References - Angelika Langer Training/Consulting

In diesem Beitrag sehen wir uns Lambda-Ausdrücke und Methoden-Referenzen an.  Beides sind neue Sprachmittel, die mit Java 8 hinzugekommen sind und einen eher funktionalen Programmierstil in Java unterstützen. 

Wie aus der „Closure-Debatte“ das „Project Lambda“ entstanden ist

Diskussionen über Spracherweiterungen in Java für funktionale Programmierung hatte es schon vor einigen Jahren gegeben.  Seit der Freigabe von Java 5 wurde heftig und intensiv darüber nachgedacht, wie solche Erweiterungen aussehen könnten.  Es gab drei konkrete Vorschläge in dieser als „Closure-Debatte“ bekannt gewordenen Anstrengung (siehe / CLO /).  Neil Gafter, vormals als Compiler-Experte bei Sun tätig, hatte sogar einen Prototyp-Compiler für den Vorschlag gebaut, an dem er mitgewirkt hatte. Dennoch hat sich keine Konvergenz der drei Closure-Vorschläge ergeben.  Es hatte auch keiner der drei Vorschläge die uneingeschränkte Unterstützung von Sun Microsystems.  Zu allem Überfluss wurde dann noch Sun Microsystems vom Oracle-Konzern übernommen und die Closure-Diskussion ist ergebnislos im Sande verlaufen. Es sah dann erst mal so aus, als würde es in Java keine Erweiterungen für die funktionale Programmierung geben.

Im Jahr 2009 hat sich dann die Erkenntnis durchgesetzt, dass Java ohne Closures (oder Lambdas, wie sie fortan hießen) gegenüber anderen Programmiersprachen veraltet aussehen könnte.  Erstens gibt es Closure- bzw. Lambda-artige Sprachmittel in einer ganzen Reihe von Sprachen, die auf der JVM ablaufen.  Zweitens braucht man auf Multi-CPU- und Multi-Core-Hardware eine einfache Unterstützung für die Parallelisierung von Programmen.  Denn, was nützen die vielen Cores, wenn die Applikation sie nicht nutzt, weil sie in weiten Teilen sequentiell und nur in geringem Umfang parallel arbeitet. 

Nun bietet der JDK mit seinen Concurrency Utilities im  java.util.concurrent -Package umfangreiche Unterstützung für die Parallelisierung.  Die Handhabung dieser Concurrency Utilities ist aber anspruchsvoll, erfordert Erfahrung und wird allgemein als schwierig und fehleranfällig angesehen.  Eigentlich bräuchte man für die Parallelisierung bequemere, weniger fehleranfällige und einfach zu benutzende Mittel.  Doug Lea, der sich schon seit vielen Jahren um die Spezifikation und Implementierung der Concurrency Utilities in Java kümmert, hat dann prototypisch eine Abstraktion  ParallelArray gebaut, um zu demonstrieren, wie eine Schnittstelle aussehen könnte für die parallele Ausführung von Operationen auf Sequenzen von Elementen (siehe / PAR /).  Die Sequenz war einfach ein Array von Elementen mit Operationen, die paralleles Sortieren, paralleles Filtern, sowie das parallele Anwenden von beliebiger Funktionalität auf alle Elemente der Sequenz zur Verfügung gestellt hat.  Dabei hat sich herausgestellt, dass eine solche Abstraktion ohne Closures/Lambdas nicht gut zu benutzen ist. 

Deshalb gibt es seitdem bei Oracle unter der Leitung von Brian Goetz (der vielen Lesern vielleicht als Autor des Buchs „Java Concurrency in Practice“ bekannt ist) ein „Project Lambda“, d.h. eine Arbeitsgruppe, die die neuen Lambda-Sprachmittel definiert und gleichzeitig neue Abstraktionen für den JDK-Collection-Framework spezifiziert und implementiert (siehe / LAM /) hat.  Ein  ParallelArray wird es in Java 8 zwar nicht geben; das war nur ein Prototyp, der Ideen geliefert hat.  Stattdessen wird es sogenannte Streams geben.  Und aus dem anfänglich als Closure bezeichneten Sprachmittel sind im Laufe der Zeit Lambda-Ausdrücke sowie Methoden- und Konstruktor-Referenzen entstanden.

Diese Lambda-Ausdrücke bzw. Methoden- / Konstruktor-Referenzen wollen wir uns im Folgenden genauer ansehen (siehe auch / TUT /).

Wie sieht ein Lambda-Ausdruck aus?

Wir haben im letzten Beitrag bereits Lambda-Ausdrücke gezeigt und zwar am Beispiel der Verwendung der  forEach -Methode.  In Java 8 haben alle Collections eine  forEach -Methode, die sie von ihrem Super-Interface  Iterable erben. Das  Iterable -Interface gibt es schon seit Java 5; es ist erweitert worden und sieht in Java 8 so aus:

public interface Iterable<T> {

    default void forEach(Consumer<? super T> action) {

        for (T t : this) {

            action.accept(t);

        }

    }

List<Integer> numbers = new ArrayList<>();

... populate list ...

Als  Consumer haben wir einen Lambda-Ausdruck übergeben (im Code farbig hervorgehoben), der alle Integer-Werte aus der Collection nach  System.out ausgibt. 

Ein Lambda-Ausdruck besteht aus einer Parameterliste (das ist der Teil vor dem " -> "-Symbol) und einem Rumpf (das ist der Teil nach dem " -> "-Symbol).  Für Parameterliste und Rumpf gibt es mehrere syntaktische Möglichkeiten.  Hier die vereinfachte Version der Syntax für Lambda-Ausdrücke:

LambdaE xpression:
  LambdaParameters '->' LambdaBody

LambdaParameters:
  Identifier
  '(' ParameterList ')'

Lambda-Parameterliste

Die Parameterliste ist entweder eine kommagetrennte Liste in runden Klammern oder ein einzelner Bezeichner ohne runde Klammern.  Wenn man die Liste in Klammern verwendet, dann kann man sich entscheiden, ob man für alle Parameter den Parametertyp explizit hinschreiben will oder ob man den Typ weglässt und ihn vom Compiler automatisch bestimmen lässt.  Hier ein paar Beispiele:

Lambda-Body

Der Rumpf ist entweder ein einzelner Ausdruck oder eine Liste von Anweisungen in geschweiften Klammern.  Hier ein paar Beispiele:

Das Prinzip für die Syntax ist recht einfach. Wenn die Parameterliste oder der Rumpf ganz simpel sind, dann darf man sogar die Klammern weglassen; wenn sie ein bisschen komplexer sind, muss man die Klammern setzen.

Typdeduktion und SAM-Typen

Die Syntax für Lambda-Ausdrücke ist knapp und kurz.  Es stellt sich die Frage: wo nimmt der Compiler all die Information her, die wir weggelassen dürfen? Wenn wir beispielsweise in der Parameterliste die Typen weglassen, dann muss der Compiler sich die Typen selber überlegen.  Wie macht er das?  Man lässt bei den Lambda-Ausdrücken grundsätzlich den Returntyp und die Exception-Spezifikation weg.  Woher nimmt der Compiler diese Information?  Was ist eigentlich überhaupt der Typ eines Lambda-Ausdrucks?  Dazu hatten wir im letzten Beitrag bereits erläutert, dass der Compiler den Typ eines Lambda-Ausdrucks aus dem umgebenden Kontext deduziert.  Sehen wir uns das noch einmal genauer an.

Zunächst einmal hat man sich beim Design der Lambda-Ausdrücke überlegt, dass das Typsystem von Java nach Möglichkeit nicht gravierend geändert werden soll.  Man hätte prinzipiell hingehen können und eine neue Kategorie von Typen für Lambda-Ausdrücke erfinden können.  Dann hätte es neben primitiven Typen, Klassen, Interfaces, Enum-Typen, Array-Typen und Annotation-Typen auch noch Funktionstypen gegeben.  Funktionstypen hätten Signaturen beschrieben, z.B.  void(String,String)IOException für einen Lambda-Ausdruck, der zwei Strings als Parameter nimmt, nichts zurück gibt und  IOException s wirft.  Diesen heftigen Eingriff ins Typsystem wollte man aber vermeiden.  Stattdessen hat man nach einer Möglichkeit gesucht, wie man herkömmliche Typen für die Lambda-Ausdrücke verwenden könnte.

Man hat sich also überlegt, welche schon existierenden Typen in Java einem Funktionstyp am ähnlichsten sind und hat festgestellt, dass es eine ganze Menge Interfaces gibt, die nur eine einzige Methode haben.  Beispiele sind  Runnable ,  Callable ,  AutoCloseable ,  Comparable ,  Iterable , usw.  Diese Interfaces beschreiben Funktionalität und ihre einzige Methode hat eine Signatur mit Parametertypen, Returntyp und Exception-Spezifikation - also genau der Information, die auch ein Funktionstyp repräsentieren würde.  Also hat man sich eine Strategie überlegt, wie man Lambda-Ausdrücke auf Interfaces mit einer einzigen Methode abbilden kann.

Solche Interfaces mit einer einzigen abstrakten Methode haben deshalb in Java 8 im Zusammenhang mit den Lambda-Ausdrücken eine besondere Bedeutung.  Man bezeichnet sie als Functional Interface Types (bisweilen auch SAM Types genannt, wobei SAM für Single Abstract Method steht).  Man kann sie mit einer speziellen Annotation, nämlich  @FunctionalInterface , markieren.  Sie sind die einzigen Typen, die der Compiler für Lambda-Ausdrücke verwenden kann.

Der SAM Type für einen Lambda-Ausdruck wird vom Java-Entwickler niemals explizit spezifiziert, sondern immer vom Compiler in Rahmen einer Typ-Deduktion aus dem Kontext bestimmt, in dem der Lambda-Ausdruck vorkommt.  Sehen wir uns dazu Beispiele von Lambda-Ausdrücken in einem Zuweisungskontext an:

BiPredicate<String,String>        sp1 =  (s,t) -> s.equalsIgnoreCase(t) ;                         // 1

BiFunction<String,String,Boolean> sp2 =  (s,t) -> s.equalsIgnoreCase(t) ;                         // 2

public interface BiPredicate<T, U> {

    boolean test(T t, U u);

}

public interface BiFunction<T, U, R> {

    R apply(T t, U u);

Auf der rechten Seite der Zuweisungen steht in beiden Fällen der gleiche Lambda-Ausdruck.  Wie passen linke und rechte Seite der Zuweisung zusammen?

Der Compiler schaut sich zunächst einmal an, ob die linke Seite der Zuweisung ein SAM Type ist. Das ist in beiden Zuweisungen der Fall.  Dann ermittelt der Compiler die Signatur der Methode in dem SAM Type.  Das  BiPredicate -Interface in Zeile //1 hat eine  test -Methode mit der Signatur  boolean(String,String ) .  Das  Bi Function -Interface in Zeile //2  hat eine  apply -Methode mit der Signatur  B oolean(String,String) . 

Nun schaut der Compiler den Lambda-Ausdruck auf der rechten Seite an und prüft, ob der Lambda-Ausdruck eine dazu passende Signatur hat.  Die Parametertypen fehlen im Lambda-Ausdruck.  Da auf der linken Seite  String s als Parameter verlangt werden, nimmt der Compiler an, dass auf der rechten Seite  s und  t vom Typ  String sein sollten.  Dann wird geprüft, ob die  String -Klasse eine Methode  equalsIgnoreCase hat, die einen  String als Argument akzeptiert.  Diese Methode existiert in der  String -Klasse; sie gibt einen  boolean -Wert zurück und wirft keine checked Exceptions.  Die Exception-Spezifikation passt also, der Returntyp passt im ersten Fall auch und im zweiten Fall mit Hilfe von Autoboxing.

Wie man sieht, hat der Compiler im Laufe dieses Deduktionsprozesses nicht nur die fehlenden Parametertypen des Lambda-Ausdrucks bestimmt, sondern auch den Returntyp und die Exception-Spezifikation.  Außerdem hat er einen SAM Type für jeden der Lambda-Ausdrücke gefunden. 

Deduktionskontext

Ein Lambda-Ausdruck kann im Source-Code nur an Stellen stehen, wo es einen Deduktionskontext gibt, den der Compiler auflösen kann.  Zulässig sind Lambda-Ausdrücke deshalb nur an folgenden Stellen:

• auf der rechten Seite von Zuweisungen (wie im obigen Beispiel),

• als Argumente in einem Methoden-Aufruf,

• als Returnwert in einer  return -Anweisung, und

• in einem Cast-Ausdruck.

Der Deduktionsprozess ist in allen Fällen ähnlich. Den Zuweisungskontext haben wir uns im obigen Beispiel bereits angesehen: bei der Zuweisung ist der Typ auf der linken Seite der Zuweisung der Zieltyp, zu dem der Lambda-Ausdruck auf der rechten Seite kompatibel sein muss.  Beim Methodenaufruf ist der deklarierte Parametertyp der aufgerufenen Methode der Zieltyp, zu dem der Lambda-Ausdruck kompatibel sein muss.  Bei der  return -Anweisung ist der deklarierte Returntyp der Methode, in der die  return -Anweisung steht, der Zieltyp.  Beim Cast-Ausdruck ist der Zieltyp des Casts der Zieltyp für den Lambda-Ausdruck.

Es kann aber auch vorkommen, dass ein Lambda-Ausdruck in einem zulässigen Kontext vorkommt und die Typdeduktion dennoch scheitert.  Hier ist ein Beispiel:

Jetzt steht der Lambda-Ausdruck in einem Cast-Kontext und der Zieltyp des Casts ist ein SAM-Typ, mit dem der Compiler die erforderliche Typdeduktion durchführen kann.

Wir haben nun die Syntax für Lambda-Ausdrücke kennen gelernt und gesehen, dass der Typ eines Lambda-Ausdruck immer vom Compiler aus dem Kontext deduziert wird und immer ein SAM-Typ sein muss.  Was darf nun im Rumpf eines Lambda-Ausdrucks stehen?  Genauer gesagt, auf welche Variablen und Felder hat man im Lambda-Body Zugriff?

Variable Binding

Im Lambda-Body hat man natürlich Zugriff auf die Parameter und lokale Variablen des Lambda-Ausdrucks.  Manchmal möchte man aber auch auf Variablen des umgebenden Kontextes zugreifen.  Hier ist ein einfaches Beispiel.  Wir verwenden darin den SAM Type  IntUnaryOperator aus dem  java.util.function -Package.  Dieser Typ sieht so aus:

@FunctionalInterface

public interface IntUnaryOperator {

    int applyAsInt(int operand);

private static void test() {

  int factor = 1000;                                                                                   // 1

  IntUnaryOperator times1000 =  (int x ) ->  { return  x * factor ; } ;                                      // 2

  Arrays.stream(new int[]{1, 2, 3, 4, 5}).map(times1000).forEach(System.out::println);                 // 3

private static void test() {

  int  factor = 1000;

  IntUnaryOperator times1000 = (int x) -> { return x *  factor ; };

  ...

   factor = 1_000_000;  // error: local variable used in lambda must be final or effectively final

  ...

class Test {

  private int  factor = 1000;

  public void test() {

    IntUnaryOperator times1000 = x -> x *  factor ;

    Arrays.stream(new int[]{1, 2, 3, 4, 5}).map(times1000).forEach(System.out::println);

     factor = 1_000_000;   // fine

  }

Die Ähnlichkeit der Regeln für Inner Classes und Lambda- Ausdrücke ist nicht verwunderlich.  Denn Lambda-Ausdrücke ähneln anonymen Klassen, die Interfaces mit genau einer abstrakten Methoden implementieren.  Verglichen mit anonymen Klassen verzichten die Lambda-Ausdrücke dabei auf jeglichen Syntax-Overhead.  Dafür muss der Compiler bei ihnen deutlich mehr Arbeit leisten und, wie weiter oben beschrieben, die fehlende Information aus dem Kontext deduzieren.

Methoden- und Konstruktor-Referenzen

Neben den Lambda-Ausdrücken gibt es die Methoden- und Konstruktor-Referenzen, die von der Syntax her noch kompakter als die Lambda-Ausdrücke sind.   Wenn man in einem Lambda-Body ohnehin nichts weiter tut, als eine bestimmte Methode aufzurufen, dann kann man den Lambda-Ausdruck häufig durch eine Methoden-Referenz ersetzen.  Das lässt sich an unserem  forEach -Beispiel von oben demonstrieren.  Hier ist noch einmal das Original-Beispiel:

List<Integer> numbers = new ArrayList<>();

... populate list ...

List<Integer> numbers = new ArrayList<>();

... populate list ...

public static <T> ThreadLocal<T> withInitial(Supplier<? extends T> supplier) {

  return new SuppliedThreadLocal<>(supplier);

@FunctionalInterface

public interface Supplier<T> {

  T get();

char[] suffix = new char[] {'.','t','x','t'};

Arrays.stream(new String[] {"readme", "releasenotes"})

      .map( StringBuilder::new )

      .map(s->s.append(suffix))

public interface Stream<T>

    <R> Stream<R> map(Function<? super T, ? extends R> mapper);

@FunctionalInterface

public interface Function<T, R> {

  R apply(T t);

char[] suffix = new char[] {'.','t','x','t'};

Arrays.stream(new String[] {"readme", "releasenotes"})

      .map(StringBuilder::new)

      .map(s->s.append(suffix))

public interface Stream<T>

  void forEach(Consumer<? super T> action);

@FunctionalInterface

public interface Consumer<T> {

  void accept(T t);

Die Verwendung von Objekten als Receiver in einer Methoden-Referenz ist nur für nicht-statische Methoden möglich, denn statische Methoden kann man über den Typ aufrufen; sie brauchen kein Objekt, auf dem sie aufgerufen werden.

Zusammenfassung und Ausblick

Wir haben uns in diesem Beitrag die Lambda-Ausdrücke und Methoden-/Konstruktor-Referenzen näher angesehen. Wir  haben die Syntax-Varianten betrachtet, die automatische Typdeduktion, die besondere Bedeutung der Functional Interface Types (aka SAM Types) und den Zugriff auf Variablen des umgebenden Kontextes aus einem Lambda-Body heraus.  Damit hat man alle Mittel in der Hand, um Lambda-Ausdrücke und Methoden-/Konstruktor-Referenzen benutzen zu können.

Im nächsten Beitrag sehen wir uns weitere Sprachneuerung an, die mit Java 8 freigegeben werden: die Default-Methoden.  Interfaces dürfen in Java 8 nicht nur abstrakte Methoden haben, sondern auch Methoden mit einer Implementierung.  Damit sind Interfaces keine reinen Abstraktionen mehr und wir sehen uns an, wie das geht und was es bedeutet.

Literaturverweise

Die gesamte  Serie über Java 8:

If you are interested to hear more about this and related topics you might want to check out the following seminar:
Seminar Lambdas & Streams - Java 8 Language Features and Stream API & Internals 3 day seminar ( open enrollment and on-site) Java 8 - Lambdas & Stream, New Concurrency Utilities, Date/Time API 4 day seminar ( open enrollment and on-site) Effective Java - Advanced Java Programming Idioms  4 day seminar ( open enrollment and on-site)	Related Reading Lambda & Streams Tutorial & Reference In-Depth Coverage of all aspects of lambdas & streams Lambdas in Java 8 Conference Presentation at JFokus 2012 (slides) Lambdas in Java 8 Conference Presentation at JavaZone 2012 (video)