Neo Tech Blog – Data. Technologie. Mobile

Martin Gerlach

Java SE 8 Neuerungen (Teil 1): Lambda-Ausdrücke und Default-Methoden

4 Kommentare


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 Software-Entwickler bei idealo, Martin Gerlach, beschreibt die wichtigsten Neuerungen im Gastbeitrag.

Lambda-Ausdrücke sparen viel Platz

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 finden 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 Lambda-Ausdrücke einsetzen kann bzw. können soll.

Aber auch für Parameter die mit “alten” funktionalen Interfaces wie z.B. 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)));

 

Methodenreferenzen

Eine interessante Ausprägung von 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 zusammen passen.
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“)

Default-Methoden in Java 8

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. in dem 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), so dass 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.

Im zweiten Teil geht es um die Stream API in Java 8.
___

Wir suchen Java Developer:

Software Developer Java (m/w)

Sr. Java Developer F&E – Schwerpunkt Computerlinguistik

Sr. Java Developer (m/w) F&E – Schwerpunkt Machine Learning/ Big Data

Senior Java Developer (m/w) – Schwerpunkt Solr / Lucene / Elastic Search

Bewirb Dich jetzt!

Martin Gerlach

Autor: Martin Gerlach

Martin Gerlach arbeitet seit 2013 als Senior Softwareentwickler im Bereich Angebotsimport bei idealo, Deutschlands größtem Preisvergleichsportal. Dort befasst er sich mit der Entwicklung perfomanter, skalierbarer Datenimport-, Transformations- und Analysetools. Sein besonderes Interesse gilt dabei verteilten Frameworks für Streaming und Analyse großer Datenmengen sowie damit einhergehenden "funktionalen" Ansätzen in der Programmierung. Vorher war Martin über 8 Jahre lang für IBM und 5 Jahre für Neofonie sowohl in Forschung und Entwicklung als auch in Kundenprojekten tätig. Er ist Master of Science Absolvent der HAW Hamburg in Informatik mit Schwerpunkt "Verteilte Systeme".

4 Kommentare

  1. „Lambda-Ausdrücke sparen so nicht nur viel Platz, sondern erhöhen die Lesbarkeit …“
    – das ist nicht wahr! Absoluter Quatsch! Es sieht sehr kryptisch aus. Es ist nur eine Zeichenfolge, die man kaum noch lesen und folgen kann.

    • Hi Andrej,

      ich nehme an, es ist Gewohnheits- bzw. Geschmackssache. Über Geschmack lässt sich bekanntlich nicht streiten, und man kann es mit den Lambdas sicher auch übertreiben, aber ich finde die kompaktere Schreibweise oft wirklich leserlicher. Beste Grüße, Martin

  2. noch ein Minus – die gute alte Autovervollständigung funktioniert auch nicht mehr.

    Und wenn man in der innere Klasse 2 Interface-Methoden implementieren soll, geht wohl auch nicht, oder?

    • Hi Andrej,

      neuere IDEs wie z.B. IDEA 14 oder NetBeans 8 bieten die Autovervollständigung ganz problemlos in Lambda-Ausdrücken an.

      Die Anmerkung zur inneren Klasse mit 2 Interface-Methoden ist korrekt. Lambda-Ausdrücke („Funktionen“) können nur dann eingesetzt werden, wenn „funktionale Interfaces“ verlangt werden, d.h. Inferfaces mit nur einer abstrakten Methode. Ein funktionales Interface beschreibt eine einzige Funktion und dabei sind nur die Parameter-Typen sowie der Return-Typ der (einzigen) Methode wichtig. Wie das Interface und die Methode heißen, ist egal.

      Beste Grüße
      Martin

Hinterlasse eine Antwort

Pflichtfelder sind mit * markiert.