Java Streams versus Schleifen: Wann eine Pipeline klarer ist und wann nicht

Worum es geht

Die Dokumentation des Pakets java.util.stream beschreibt einen Stream als eine Folge von Elementen, die sequenzielle und parallele Aggregatoperationen unterstützt: eine Quelle (Collection, Array, Generator), Zwischenoperationen (filter, map, sorted, distinct, limit) und eine terminale Operation (collect, reduce, forEach, findFirst, count). Zwischenoperationen sind stets lazy; nichts läuft, bevor die terminale Operation aufgerufen wird, danach ist die Pipeline verbraucht. Die Dokumentation von Stream besagt, dass ein Stream nur einmal verwendet werden sollte und eine Wiederverwendung eine IllegalStateException auslösen kann. Die Paketdokumentation verlangt, dass die Verhaltensparameter (die Lambdas) die Quelle nicht stören (non-interfering), erwartet sie in den meisten Fällen zustandslos und besagt, dass Seiteneffekte darin generell unerwünscht sind und weggelassen oder umgeordnet werden können.

Warum es wichtig ist

Wer von Python, JavaScript oder C# LINQ kommt, liest Pipelines mühelos und neigt dazu, sie überall einzusetzen. Die Kosten zeigen sich an drei Stellen: beim Debuggen (Stacktraces durch das Innere der Pipeline), bei geprüften Exceptions (ein Lambda in map kann keine IOException werfen, ohne sie einzupacken) und bei der Lesbarkeit, sobald die Pipeline einen Index, zwei im Gleichschritt laufende Sequenzen oder einen vorzeitigen Abbruch mit akkumuliertem Zustand braucht. Eine Pipeline, die nur existiert, um forEach mit Seiteneffekten aufzurufen, ist eine Schleife in teurerer Syntax.

So wird es angewendet

• Einen Stream verwenden, wenn die Berechnung eine reine Transformation ist: Filtern, Abbilden, Gruppieren (Collectors.groupingBy), Verknüpfen (Collectors.joining), Summieren oder das erste Element finden. Das Ergebnis benennen und die Pipeline kürzer als einen Bildschirm halten.
• Eine Schleife verwenden, wenn der Rumpf gemeinsamen Zustand verändert, break oder continue unter mehreren Bedingungen braucht, geprüfte Exceptions wirft, zwei Sequenzen gemeinsam durchläuft oder den Index benötigt.
• Aus einer Pipeline toList() (unveränderlich) zurückgeben oder Collectors.toCollection(...), wenn die aufrufende Stelle einen bestimmten veränderlichen Typ braucht.
• parallel() als eine zu messende Optimierung behandeln, nicht als Standard; zustandsbehaftete und geordnete Operationen mindern den Nutzen, und die Dokumentation warnt, dass die Reihenfolge von Seiteneffekten bei paralleler Ausführung überraschend sein kann.
• Einen Stream nicht in einem Feld ablegen oder aus einer öffentlichen API zurückgeben, ausser die aufrufende Stelle wird ihn genau einmal konsumieren.

Stolpersteine

Das Optional von findFirst verleitet zu .get() ohne Prüfung. Collectors.toMap wirft laut Dokumentation bei doppelten Schlüsseln eine IllegalStateException, sofern keine Merge-Funktion angegeben wird. sorted puffert die gesamte Eingabe. Ein Lambda, das die Quell-Collection verändert, verletzt die Non-Interference und kann ohne Fehlermeldung falsche Ergebnisse liefern.