Lambda Ausdrücke und Default-Methoden in Java SE 8

Mit der Version 8 der Java Standard Edition stehen Java-Entwicklern ab sofort zwei mächtige neue Sprach-Features zur Verfügung: Lambda Ausdrücke (“Lambda Expressions”, inoffiziell auch “Closures” genannt), welche in anderen JVM-Sprachen wie Groovy, Scala und insb. Clojure bereits vorher unterstützt wurden, sowie Default-Methoden (“Virtual Extension Methods”) für Interfaces. Beide Konstrukte ermöglichen es, in Java viel eleganter als bisher Elemente der funktionalen Programmierung, wie etwa die Anwendung von Funktionen auf Streams zu nutzen. Der ehemalige Neofoniker und jetzige Senior Softwareentwickler bei idealo, Martin Gerlach, beschreibt die wichtigsten Neuerungen im Gastbeitrag.

Lambda Ausdrücke beschreiben Funktionsobjekte. So lässt sich eine Funktion, die die Summe von zwei Argumenten liefert, wie folgt im Code ausdrücken:

(i, j) -> i + j

Die Angabe der Parametertypen ist nur dann erforderlich, wenn der Compiler sie nicht selbst aus dem Kontext des Ausdrucks ableiten kann. Diese Fähigkeit der “Type Inference” spielte erstmals mit der Einführung von Generics zur Verbesserung der Typsicherheit und Vermeidung der Notwendigkeit von Typumwandlungen (“Typecasts”) bei Verwendung von Collections in Java SE 5 (Sept. 2004) eine Rolle und wurde mit den folgenden Versionen immer weiter verbessert, zuletzt in Java SE 7 mit dem “Diamond Operator” (<>).

Tatsächlich kann man obigen Ausdruck an jeder Stelle einsetzen, an der eine Variable oder ein Parameter durch die Angabe eines Interfaces mit genau einer abstrakten Methode, eines sog. funktionalen Interfaces typisiert ist, z.B.

interface IntOp { int apply(int arg1, int arg2); }

interface DoubleOp { double apply(double arg1, double arg2);  }

…

int calcInt(int i1, int i2, IntOp op) { return op.apply(i1, i2);  }

int calcDouble(double d1, double d2, DoubleOp op) {

return op.apply(d1, d2);  }

…

int i1 = calcInt(1, 2, (i, j) -> i + j); // i1 == 3

int i2 = calcInt(1, 2, (i, j) -> i – j); // i2 == -1

double d = calcDouble(1.1, 2.2, (i, j) -> i + j); // d == 3.3

Dabei ist es unerheblich wie die abstrakte Interface-Methode heißt, wichtig sind die Typen der formalen Parameter und des Rückgabewertes. Der Compiler weiß anhand der Methodendeklaration, dass die Funktionsargumente (Methodenparameter) i und j in den Ausdrücken für i1 und i2 vom Typ int sein müssen und im Ausdruck für d vom Typ double. Autoboxing/-unboxing sowie implizite Typenumwandlungen (z.B. von int nach long) funktionieren dabei wie gewohnt.

Lambda-Ausdrücke sparen so nicht nur viel Platz, sondern erhöhen die Lesbarkeit und damit auch die Wartbarkeit gegenüber Code wie diesem hier ungemein:

int i1 = calcInt(1, 2, new IntOperator() { // before Java 8…


     @Override

     public int apply(int i, int j) {

          return i + j;

    }

});

Allgemeine funktionale Interfaces befinden sich in Java 8 im Package java.util.function, darunter auch Function<T, R> { R apply (T t); } und diverse Varianten für primitive Typen. Diese Interfaces können überall dort als Parameter-Typen für Methoden verwendet werden, wo aufrufender Code Java Lambda Ausdrücke einsetzen kann, beziehungsweise können soll.

Aber auch für Parameter die mit “alten” funktionalen Interfaces wie Comparator<T> (siehe weiter unten), oder auch dem Spring-jdbc RowMapper<T> typisiert sind, können Lamdba Ausdrücke eingesetzt werden, z.B. im folgenden Aufruf von public <T> List<T> JdbcTemplate.query(String, RowMapper<T>):

List<ID> customerIDs = jdbcTemplate.query(„select id from customer“,

(resultSet, rowNum) -> new ID(resultSet.getLong(rowNum)));

Eine interessante Ausprägung von Java Lambda Ausdrücken sind Methodenreferenzen. Der Ausdruck für i1 aus dem obigen Beispiel lässt sich auch wie folgt schreiben:

int i1 = calcInt(1, 2, Integer::sum);

Das ist äquivalent zu:

int i1 = calcInt(1, 2, (i, j) -> Integer.sum(i, j));

Nicht nur statische Methoden wie Integer.sum(int, int), sondern auch Konstruktoren für Objekte und Arrays sowie Instanzmethoden lassen sich so als Funktionen übergeben, sofern formale Parameter und Rückgabewerte zusammenpassen.

Konstruktoren-Referenzen schreibt man mittels ::new, z.B. ArrayList::new, String[]::new, int[]::new. Damit kann nicht nur der Default-Konstruktor referenziert werden, sondern auch Konstruktoren mit Parametern. Es kommt darauf an, welcher gerade passt. Wird z.B. die Methode:

void myMethod(Function<Integer, List<String>> f) { … f.apply(2); … }

wie folgt aufgerufen: myMethod(ArrayList::new);

so wäre das Äquivalent zu myMethod(n -> new ArrayList<>(n));  und innerhalb der Methode würde durch den Aufruf f.apply(2) tatsächlich new ArrayList<String>(2) aufgerufen werden.

Instanzmethoden der Klasse des ersten formalen Parameters der abstrakten Methode eines funktionalen Interfaces können in einem Lambda Ausdruck für diese Methode ebenso referenziert werden, sofern die restlichen Parameter und der Rückgabewert passen:

String[] names = nameService.getAllNames();

Arrays.sort(names, String::compareToIgnoreCase);

public compareToIgnoreCase(String) ist eine Instanzmethode der Klasse String. public static <T> void sort(T[], Comparator<? super T>) ist eine statische Methode der Klasse java.util.Arrays. Weshalb man die Instanzmethode compareToIgnoreCase als Comparator einsetzen darf, wird deutlich, wenn man bedenkt, dass Comparator<T> ein funktionales Interface ist. Es gibt nur eine Methode int compare(T a, T b), was nichts anderes heißt, als dass man überall dort, wo ein Comparator erwartet wird, auch einen Lambda-Ausdruck mit zwei Parametern vom Typ T sowie Rückgabewert vom Typ int einsetzen darf. String::compareToIgnoreCase kann man auch als (a, b) -> a.compareToIgnoreCase(b) schreiben. Parameter und Rückgabewert entsprechen genau der abstrakten Methode des Interfaces Comparator<String> – und übrigens auch jener des Interfaces BiFunction<String, String, Integer>:

Comparator<String> cmp1 = String::compareToIgnoreCase;

assert cmp1.compare(„a“, „A“) == 0; // „a“.equalsIgnoreCase(„A“)

BiFunction<String, String, Integer> cmp2 =


String::compareToIgnoreCase;

assert cmp2.apply(„a“, „A“) == 0; // „a“.equalsIgnoreCase(„A“)

Instanzmethoden von konkreten Instanzen lassen sich übrigens auch referenzieren:

final String a = „a“;

Function<String, Integer> cmp3 = a::compareToIgnoreCase;

assert cmp3.apply(„A“) == 0; // a.compareToIgnoreCase(„A“)

Am Beispiel des Interfaces Comparator<T> lässt sich die zweite signifikante Neuerung in Java 8 anschaulich beschreiben. Es gibt in dem Interface nun nicht mehr nur die eine abstrakte Methode int compare(T, T), sondern mit Java 8 auch jede Menge Default-Methoden und statische Methoden. Statische Methoden in Interfaces entsprechen größtenteils statischen Methoden in Klassen, werden jedoch nicht “vererbt”, sondern müssen immer über ihr definierendes Interface in der Form Interface.staticMethod(…) aufgerufen werden. Default-Methoden sind weitaus interessanter. Sie bieten die Möglichkeit, nachträglich Interface-Methoden hinzuzufügen ohne existierenden Code von Klassen, die ein so erweitertes Interface implementieren, verändern zu müssen. Default-Methoden stehen in allen implementierenden Klassen zur Verfügung, werden also vererbt und können auch in implementierenden Klassen überschrieben werden.

Comparator<T> definiert nun einige statische Factory-Methoden sowie Default-Methoden, die dann auf den durch die Factories erzeugten Instanzen aufgerufen werden können. Mit den folgenden (etwas vereinfacht aufgelisteten) Methoden von Comparator<T> …

static <T,U> Comparator<T> comparing(Function<T,U>, Comparator<U>)

static <T> Comparator<T> nullLast(Comparator<T>)

static <T> Comparator<T> naturalOrder()

static <T> Comparator<T> reverseOrder()

default <U> Comparator<T> thenComparing(Function<T,U>, Comparator<U>)

… kann man unter Zuhilfenahme von Methodenreferenzen und einigen Static-Imports z.B. folgenden Comparator für eine Klasse Person mit den Eigenschaften lastName, firstName und birthdate schreiben:

Comparator<Person> cmp =


nullLast(comparing(Person::getBirthdate, reverseOrder()))

.thenComparing(Person::getLastName, naturalOrder())

.thenComparing(Person::getFirstName, naturalOrder());

Wie eine Personenliste durch diesen Comparator sortiert wird, dürfte der Code selbst erklären.
Eine umfassende Auflistung von Interfaces und Klassen, die in ähnlicher Art und Weise erweitert wurden oder in Java 8 neu hinzugefügt wurden, um die Vorteile von Lambda Ausdrücken zu nutzen, findet sich hier.

Da Java-Klassen mehr als ein Interface implementieren können, ist mit Java 8 nun die Mehrfachvererbung von Default-Methoden möglich. Das kann genau wie in anderen Sprachen mit Mehrfachvererbung zu Konflikten führen: Haben zwei Interfaces A und B je eine Default-Methode mit derselben Signatur, z.B. void defaultMethod(), so muss in einer Klasse, die beide Interfaces (direkt oder indirekt) implementiert und in deren Klassenhierarchie(n) die Default-Methode nicht überschrieben wurde, die Default-Methode zwingend überschrieben werden, z.B. indem explizit eine der beiden Varianten aufgerufen wird:

class X implements A, B {

     @Override public void defaultMethod() {

           A.super.defaultMethod(); // calls implementation in A

     }

}

Alternativ kann die Default-Methode in der Klasse X auch als abstrakt deklariert werden (sofern X auch abstrakt ist), sodass die Konfliktauflösung den Subklassen von X überlassen wird.

Ausführliche Informationen über alle Aspekte von Lambdas und Default-Methoden finden sich beispielsweise in Richard Warburton, “Java 8 Lambdas – Functional Programming for the Masses”, O’Reilly 2014.

Veröffentlichung am 17. November 2014, aktualisiert am 07. Oktober 2020