| Angelika Langer - Training & Consulting |
|
|
| HOME | |
|
|
|
|
OVERVIEW
BY COLUMN
BY MAGAZINE
|
|
| GENERICS | |
| LAMBDAS | |
| IOSTREAMS | |
| ABOUT | |
| CONTACT |
|
Java 8
Lambda-Ausdrücke und Methoden-Referenzen
Java Magazin, November 2013
|
Dies ist die Überarbeitung eines Manuskripts für einen Artikel, der im Rahmen einer Kolumne mit dem Titel "Effective Java" im Java Magazin erschienen ist. Die übrigen Artikel dieser Serie sind ebenfalls verfügbar ( click here ). |
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
Wie sieht ein Lambda-Ausdruck aus?
public interface Iterable<T> {
Iterator<T> iterator();
default void forEach(Consumer<? super T> action) {
for (T t : this) {
action.accept(t);
}
}
}
Das
Iterable
-Interface
hat zusätzlich zur
iterator
-Methode,
die es schon immer hatte, eine
forEach
-Methode
bekommen. Die
forEach
-Methode iteriert
über alle Elemente in der Collection und wendet auf jedes Element eine
Funktion an, die der Methode als Argument vom Typ
Consumer
übergeben wird. Die Benutzung der
forEach
-Methode
sieht dann zum Beispiel so aus:
List<Integer> numbers = new ArrayList<>();
... populate list ...
numbers.forEach(
i ->
System.out
.
println
(i)
);
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 ')'
LambdaBody:
Expression
Block
Lambda-Parameterliste
| (int x) -> x+1 | Parameterliste mit einem einzigen Parameter mit expliziter Typangabe . |
| int x -> x+1 | Falsch: Wenn man den Parametertyp angibt, muss man die runden Klammern verwenden. |
| (x) -> x+1 | Parameterliste mit einem einzigen Parameter ohne explizite Typangabe ; der Compiler deduziert den fehlenden Parametertyp aus dem Kontext. Das sehen wir uns später noch genauer an. |
| x -> x+1 | Parameterliste mit einem einzigen Parameter ohne explizite Typangabe. I n diesem Fall darf man die runden Klammern weglassen. |
| (int x,int y) -> x+y | Parameterliste mit zwei Parameter n mit expliziter Typangabe . |
| int x,int y -> x+y | Falsch: Wenn man den Parametertyp angibt, muss man die runden Klammern verwenden. |
| (x,y) -> x+y | Parameterliste mit zwei Parameter n ohne explizite Typangabe. |
| x,y -> x+y | Falsch: Bei mehr als einem Parameter muss die runde Klammer verwendet werden. |
| (x, int y) -> x+y | Falsch: Man darf Parameter mit und ohne Typangabe nicht mischen. Entweder alle haben eine explizite Typangabe oder keiner. |
| () -> 42 | Die Parameterliste darf leer sein. |
Lambda-Body
| () -> System.gc() | Body bestehend aus einem einzigen Ausdruck. |
|
(String[]
args)
-> (args != null) ? args.length : 0 |
Der ?: -Operator ergibt auch einen einzigen Ausdruck. |
|
(String[]
args)
-> { if(args != null) return args.length ; else return 0 ; } |
Body bestehend aus einer if -Anweisung . Hier werden geschweifte Klammern gebraucht , weil es eine Anweisung und kein Ausdruck ist. |
| (int x) -> x+1 | Body bestehend aus einem einzigen Ausdruck. |
| (int x) -> return x+1 | Falsch: Mit return fängt eine Anweisung an und kein Ausdruck; die return -Anweisung muss mit einem Semikolon enden und gehört in geschweifte Klammen. |
| (int x) -> { return x+1 ; } | So ist es richtig. |
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
Auf der linken Seite der
beiden Zuweisungen stehen Variablen vom Typ
BiPredicate<String,String>
bzw.
BiFunction<String,String,Boolean>
.
BiPredicate
und
BiFunction
sind Interfaces aus dem
Package
java.util.function
, das es in
Java 8 im JDK gibt. Die Interfaces sehen (vereinfacht) so aus:
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
Object o =
(s,t)
-> s.equalsIgnoreCase(t
)
; //
error: Object is not a functional type
Das ist ein Zuweisungskontext
und deshalb prinzipiell erlaubt, aber der Typ
Object
auf der linken Seite ist kein SAM-Typ. Also scheitert die Typdeduktion.
Hier kann man sich behelfen, indem man einen Cast einfügt.
Object o = (BiPredicate<String,String>)
(s,t)
-> s.equalsIgnoreCase(t
)
;
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
@FunctionalInterface
public interface IntUnaryOperator {
int applyAsInt(int operand);
}
Das Beispiel selbst verwendet diverse Abstraktionen
aus dem Stream-Framework und sieht so aus.
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
}
Nur kurz zur Erläuterung: in Zeile //3 machen
wir aus einem
int
-Array einen
Stream
,
dessen
map
-Methode wir benutzen, um alle
Elemente in dem Array mit Hilfe der Funktion
times1000
auf einen neuen
int
-Wert abzubilden und
anschließend werden die neuen Werte nach
System.out
ausgegeben. Eigentlich geht es aber um den blau eingefärbten Lambda-Ausdruck.
Wir verwenden im Lambda-Body nicht nur den
Parameter
x
des Lambda-Ausdrucks, sondern
auch die Variable
factor
aus dem umgebenden
Kontext. Das ist erlaubt. Alle Variablen, die im Lambda-Ausdruck verwendet
werden, aber nicht im Lambda-Ausdruck selbst definiert wurden, haben dieselbe
Bedeutung wie im umgebenden Kontext. Die einzige Voraussetzung ist, dass
die betreffenden lokalen Variablen "effectively final" sind, d.h. sie dürfen
nicht geändert werden - weder im Lambda-Ausdruck noch im umgebenden Kontext.
[1]
Folgendes wäre also falsch:
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
...
}
Dieses Binden von Namen in einem Lambda-Ausdruck
an lokale Variablen, die außerhalb des Lambda-Ausdrucks definiert sind,
ähnelt dem Binding, das auch in lokalen und anonymen Klassen erlaubt ist.
Lokale und anonyme Klassen hatten schon immer Zugriff auf
final
-Variablen
des umgebenden Kontextes. In Java 8 hat man übrigens die Regeln gelockert.
Analog zu den Lambda-Ausdrücken haben in Java 8 auch die lokalen und anonymen
Klassen Zugriff auf alle "effectively final"-Variablen des umgebenden Kontextes.
Eigentlich ist alles so wie vorher, nur muss man das
final
nicht mehr explizit hinschreiben; der Compiler ergänzt es einfach, sobald
eine Variable in einer lokalen oder anonymen Klasse (oder in einem Lambda-Ausdruck)
verwendet wird.
Lambda-Ausdrücke haben außerdem Zugriff auf Felder der Klasse, in
der sie definiert sind. Hier ist ein Beispiel:
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
}
}
Dieses Mal ist
factor
keine lokale Variable in der Methode, in der der Lambda-Ausdruck vorkommt,
sondern
factor
ist ein Feld der Klasse,
in der der Lambda-Ausdruck definiert ist. Bei Feldern wird nicht verlangt,
dass sie
final
oder "effectively final"
sein müssen. Der Lambda-Ausdruck hat ganz normalen, uneingeschränkten
Zugriff darauf. Auch dies gilt für Lambda-Ausdrücke wie bisher für
Inner Classes.
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
List<Integer> numbers = new ArrayList<>();
... populate list ...
numbers.forEach(
i ->
System.out.println(i)
);
Anstelle des Lambda-Ausdruck kann man eine
Methoden-Referenz verwenden. Dann sieht es so aus:
List<Integer> numbers = new ArrayList<>();
... populate list ...
numbers.forEach(
System.out
::
println
);
Alles bisher über Lambda-Ausdrücke Gesagte,
gilt auch für Methoden-Referenzen: sie dürfen nur in einem Kontext
vorkommen, in dem der Compiler eine Typ-Deduktion machen und einen SAM
Type für die Methoden-Referenz bestimmen kann. Der Deduktionsprozess
ist ähnlich, lediglich mit dem Unterschied, dass der Compiler für eine
Methoden-Referenz noch mehr Informationen deduzieren muss. Beispielsweise
fehlt bei einer Methoden-Referenz nicht nur der Typ der Parameter, sondern
auch jegliche Information über die Anzahl der Parameter.
Syntaktisch betrachtet besteht eine Methoden-Referenz
aus einem
Receiver
(das ist der Teil vor dem "
::
"-Symbol)
und einem Methodennamen (das ist der Teil nach dem "
::
"-Symbol).
Der Receiver kann - wie im obigen Beispiel - ein Objekt sein; es kann aber
auch ein Typ sein. Der Methodenname ist entweder der Name einer existierenden
Methode oder "
new
"; mit "
new
"
werden Kostruktoren referenziert. Sehen wir uns einige Beispiele an.
String
Builder
::new
ist eine Konstruktor-Referenz. Der Receiver ist in diesem Falle kein
Objekt, sondern ein Typ, nämlich die Klasse
String
Builder
.
Offensichtlich wird ein Konstruktor der
String
Builder
-Klasse
referenziert. Die
String
Builder
-Klasse
hat aber eine ganze Reihe von überladenen Konstruktoren. Welcher der
Konstruktoren mit
String
Builder
::new
gemeint ist, hängt vom Kontext ab, in dem die Konstruktor-Referenz auftaucht.
Hier ist ein Beispiel für einen Kontext, in dem die Konstruktor-Referenz
String
Builder
::new
vorkommt:
ThreadLocal<StringBuilder> localTextBuffer = ThreadLocal.withInitial(
StringBuilder::new
);
Die Method
withInital
-Methode
der Klasse
ThreadLocal
sieht so aus:
public static <T> ThreadLocal<T> withInitial(Supplier<? extends T> supplier) {
return new SuppliedThreadLocal<>(supplier);
}
Der verwendete SAM-Typ
Supplier
sieht so aus:
@FunctionalInterface
public interface Supplier<T> {
T get();
}
Der Compiler deduziert aus diesem Kontext,
dass die Konstruktor-Referenz
String
Builder
::new
vom Typ
Supplier<StringBuilder>
sein muss, d.h. eine Funktion, die keine Argumente nimmt und einen
StringBuilder
zurück gibt. Es ist also in diesem Kontext der No-Argument-Konstruktor
der
String
Builder
-Klasse
gemeint.
Hier ist ein anderer Kontext, in dem die
Konstruktor-Referenz
String
Builder
::new
vorkommt:
char[] suffix = new char[] {'.','t','x','t'};
Arrays.stream(new String[] {"readme", "releasenotes"})
.map( StringBuilder::new )
.map(s->s.append(suffix))
.forEach(System.out::println);
Hier taucht die Konstruktor-Referenz als
Argument der
map
-Methode eines
Stream<String>
vor. Die betreffende
map
-Methode sieht
so aus:
public interface Stream<T>
<R> Stream<R> map(Function<? super T, ? extends R> mapper);
}
Der verwendete SAM-Typ
Function
sieht so aus:
@FunctionalInterface
public interface Function<T, R> {
R apply(T t);
}
In diesem Kontext deduziert der Compiler,
dass die Konstruktor-Referenz
String
Builder
::new
vom Typ
Function<String,StringBuilder>
sein muss, also eine Funktion, die einen
String
als Argument nimmt und einen
StringBuilder
zurück gibt. Es ist also in diesem Kontext der Konstruktor der
String
Builder
-Klasse
gemeint, der einen
String
als Argument
akzeptiert.
Wie man sieht, sind Methoden- und Konstruktor-Referenzen
sehr flexibel, weil mit einem einzigen syntaktischen Gebilde wie
String
Builder
::new
eine
ganze Reihe von Methoden bzw. Konstruktoren bezeichnet werden und der Compiler
den richtigen von allein herausfindet.
In den obigen Beispielen haben wir Konstruktor-Referenzen
gesehen. Der Receiver ist dabei immer ein Typ. Bei Methoden-Referenzen
ist als Receiver neben einem Typ alternativ auch ein Objekt erlaubt.
Das sieht man am Beispiel von
System.out::println
.
Wir haben diese Methoden-Referenzen mehrfach als Argument der
forEach
-Methode
benutzt. Zum Beispiel hier:
char[] suffix = new char[] {'.','t','x','t'};
Arrays.stream(new String[] {"readme", "releasenotes"})
.map(StringBuilder::new)
.map(s->s.append(suffix))
.forEach(
System.out::println
);
Die betreffende
forEach
-Methode
sieht so aus:
public interface Stream<T>
void forEach(Consumer<? super T> action);
}
Der verwendete SAM-Typ
Function
sieht so aus:
@FunctionalInterface
public interface Consumer<T> {
void accept(T t);
}
In diesem Kontext muss die Methoden-Referenz
System.out::println
vom Typ
Consumer<? super StringBuilder>
sein, also eine Methode, die einen
StringBuilder
oder einen Supertyp von
StringBuilder
als Argument nimmt und nichts zurückgibt. Nun ist das Objekt
System.out
vom Typ
PrintStream
und die Klasse
PrintStream
hat eine passende nicht-statische
println
-Methode,
die ein
Object
(also einen Supertyp von
StringBuilder
)
als Argument nimmt. Diese
println
-Methode
ist aber nicht-statisch und benötigt daher für den Aufruf ein Objekt
vom Typ
PrintStream
, auf dem sie gerufen
wird, und das
Object
, das als Argument
übergeben wird. Eigentlich hat die
println
-Methode
die Signatur
void(PrintStream,Object)
,
d.h. sie braucht zwei Objekte für den Aufruf.
Wenn man nun als Receiver für die
println
-Methode
nicht den Typ
PrintStream
angibt, sondern
ein
PrintStream
-Object wie z.B.
System.out
,
dann ist das erste Argument bereits versorgt und die Methoden-Referenz
hat die Signatur
void(
Object)
,
d.h. sie braucht nur noch ein Objekt für den Aufruf.
Es macht also einen Unterschied, wie ich
eine Methoden-Referenz hinschreibe. Die Referenz
PrintStream::println
hat die Signatur
void(PrintStream,Object)
mit zwei Argumenten; die Referenz
System.out
::println
hat die Signatur
void(
Object)
mit nur einem Argument.
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
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
| /PAR/ |
Brian Goetz
Accelerate sorting and searching with the ParallelArray classes in Java 7 URL: http://www.ibm.com/developerworks/java/library/j-jtp03048/index.html |
| /CLO/ |
Klaus Kreft, Angelika Langer
Understanding the closures debate URL: http://www.javaworld.com/javaworld/jw-06-2008/jw-06-closures.html |
| /LAM/ |
Project Lambda
URL: http://openjdk.java.net/projects/lambda/ |
| /TUT/ |
Angelika Langer, Klaus Kreft
Lambda Tutorial URL: http://www.AngelikaLanger.com/Lambdas/Lambdas.html |
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
|
Related Reading
|
||||||||||||
URL:
<
http://www.AngelikaLanger.com/Articles/EffectiveJava/71.Java8.Lambdas/71.Java8.Lambdas.html>
last update: 26 Oct 2018