Seite 2: Wandel der Stream-API von Java 8 bis 21 – eine Übersicht

Seit ihrer Einführung in Java 8 hat die Stream-API die Art und Weise, wie Daten in Java verarbeitet werden, grundlegend verändert. Mit dem Ziel, deklarative, funktional inspirierte Datenflüsse zu ermöglichen, etablierte sie ein neues Programmierparadigma innerhalb der objektorientierten Sprache. Die initiale Version war bereits bemerkenswert ausdrucksstark: Sie bot eine klare Trennung zwischen Datenquelle, Transformation und Terminaloperation, unterstützte Lazy Evaluation und ließ sich sowohl sequenziell als auch parallel ausführen. Insbesondere die Integration mit Lambdas, Method References und der java.util.function-Bibliothek ermöglichte einen flüssigen, typgesicherten Stil der Datenverarbeitung, der zuvor nur über externe Bibliotheken oder explizite Iteratoren realisierbar war.

In den darauffolgenden JDK-Versionen wurde die Stream-API nicht grundlegend neu gestaltet, aber stetig erweitert, verfeinert und stabilisiert. Java 9 brachte die ersten signifikanten Erweiterungen mit sich, etwa durch die Methoden takeWhile, dropWhile und iterate mit Prädikaten, die es ermöglichten, Stream-Pipelines noch präziser zu kontrollieren und bei Bedarf vorzeitig zu terminieren. Diese Erweiterungen schlossen eine semantische Lücke in der ursprünglichen API und verbesserten insbesondere die Modellierbarkeit komplexerer Datenflüsse. Auch die Einführung von Optional.stream() war ein bemerkenswerter Schritt, da sie eine elegante Brücke zwischen den Typen Optional und Stream schlug und damit die Kompositionsfähigkeit im funktionalen Stil weiter erhöhte.

In den Java-Versionen 10 bis 14 kamen vorrangig begleitende Sprachfeatures wie var hinzu, die zwar nicht direkt die Stream-API selbst veränderten, aber deren Lesbarkeit und Anwendbarkeit in verschiedenen Kontexten verbesserten. Erst mit Java 16 und der konsequenten Verbreitung von Records als kompakte Datencontainer gewann die Stream-Verarbeitung erneut an Ausdrucksstärke. Fortan ließ sie sich mit strukturierten, aber unveränderlichen Datenmodellen kombinieren – ein klarer Vorteil für parallele oder deterministische Verarbeitungsszenarien.

Die Long-Term-Support-Version Java 17 festigte die API durch zusätzliche Optimierungen im Backend und eine weiter verbesserte Integration mit dem Pattern Matching und der modernen sealed-Klassenhierarchie. Diese strukturellen Verbesserungen führten nicht zu neuen Methoden in der Stream-Klasse selbst, ermöglichten jedoch einen präziseren Umgang mit heterogenen Datenflüssen und die Formulierung domänenspezifischer Pipelines auf hohem Abstraktionsniveau.

Erst Java 21 brachte wieder greifbare Erweiterungen im Bereich funktionaler Datenverarbeitung, insbesondere im Zusammenspiel mit Scoped Values, strukturierter Nebenläufigkeit und der weiterentwickelten ForkJoinPool-Implementierung. Während die Stream-API formal kaum neue Methoden erhielt, wurde ihre Anwendbarkeit im Kontext nebenläufiger und speicheroptimierter Architekturen deutlich gestärkt. Auch die gestiegene Performance bei paralleler Ausführung und die effizientere Verwaltung von Intermediate Results sind Ausdruck einer Reifung der API auf der Implementationsebene. Seit Java 21 lassen sich Streams nicht nur eleganter schreiben, sondern auch sicherer und vorhersehbarer ausführen – insbesondere im Umfeld asynchroner oder reaktiver Verarbeitung.

Zusammenfassend lässt sich sagen, dass die Stream-API von Java 8 bis Java 21 einen erkennbaren Reifungsprozess durchlaufen hat. Während ihr konzeptioneller Kern weitgehend konstant blieb, wurde ihr semantischer Umfang präzisiert, ihre Integration mit modernen Sprachmitteln vertieft und ihre Effizienz auf mehreren Ebenen optimiert.

Ein konkretes Beispiel mit flatMap und mapMulti – konzeptueller Unterschied

Eingeführt mit Java 8 basiert flatMap auf der Idee, dass eine Funktion zum Einsatz kommt, die für jedes Element des ursprünglichen Streams einen neuen Stream produziert. Diese verschachtelten Streams werden anschließend so zusammengeführt, sodass der resultierende Stream eine flache Struktur hat. Dieses Pattern ist sehr mächtig und erlaubt elegante Transformationen verschachtelter Datenstrukturen – etwa Stream<List<T>> zu Stream<T>.

mapMulti(), eingeführt in Java 16, verfolgt hingegen einen anderen Ansatz. Statt verschachtelte Streams zu erzeugen, kommt hier eine Consumer-basierte Schnittstelle zum Einsatz: Die Methode erhält für jedes Element des Streams einen BiConsumer, über den Entwickler direkt null, ein oder mehrere Ausgabewerte an den restlichen Stream (Downstream) liefern können – ohne temporäre Datenstrukturen wie Listen oder Streams zu erzeugen. Dadurch lassen sich Heap-Allokationen vermeiden, was insbesondere in performanzkritischen Szenarien eine relevante Rolle spielt.

Das Beispiel setzt die folgende Datenstruktur voraus:

private static List<List<String>> DATA = List.of(
   List.of("a", "b"),
   List.of("c"),
   List.of(),
   List.of("d", "e")
);

Beispiel mit flatMap

List<String> result = DATA
   .stream()
   .flatMap(List::stream)
   .collect(Collectors.toList());

Hier wird jede innere Liste in einen Stream umgewandelt und anschließend "abgeflacht".

Beispiel mit mapMulti()

List<String> result = DATA
   .stream()
   .<String>mapMulti(Iterable::forEach)
   .toList();

In diesem Fall wird keine neue Stream-Instanz erzeugt, sondern der Inhalt über die forEach-Schleife direkt an den Consumer übergeben.

flatMap steht eher für deklarative Klarheit und konzeptuelle Einfachheit. Die Methode bildet ein fundamentales Prinzip funktionaler Programmierung ab und ist somit besonders gut geeignet, wenn die Transformation auf Basis vorhandener Stream<T>-erzeugender Funktionen erfolgt. Sie eignet sich vor allem für Lesbarkeit und funktionales Denken, bringt jedoch eine gewisse Overhead-Struktur durch temporäre Streams mit sich.

mapMulti() hingegen zielt auf Optimierung ab. Die Methode ermöglicht es, Transformationen effizienter auszudrücken, indem sie direkte Kontrolle über die Ausgabe gewährt. Dies reduziert Heap-Allokationen, erlaubt bessere Speicherlokalität (geringere Fragmentierung) und ist daher aus Sicht der JVM-Optimierung vorzuziehen, wenn Performance im Vordergrund steht. Allerdings ist der semantische Ausdruck komplexer: Nutzer müssen explizit mit Consumer-Logik arbeiten, was die Lesbarkeit und Verständlichkeit für in funktionaler Programmierung weniger versierte Entwickler einschränken kann.

Zusammenfassend lässt sich festhalten, dass flatMap der idiomatische, funktionale Weg bleibt, während mapMulti() ein gezieltes Werkzeug für performante Datenverarbeitung darstellt. Ihre Koexistenz innerhalb der Stream-API zeigt den Anspruch von Java, sowohl Ausdrucksstärke als auch Effizienz innerhalb desselben Paradigmas zu vereinen – ein Balanceakt zwischen deklarativer Eleganz und systemnaher Kontrolle.

Was mit Java 24 hinzugekommen ist: (Stream) Gatherers

Mit Java 24 wurde die Stream-API um ein neues Konzept erweitert: Gatherers. Diese Ergänzung schließt eine lang bestehende Lücke in der Stream-Verarbeitung: die Fähigkeit, benutzerdefinierte Aggregationen über mehrere Elemente hinweg in kontrollierter, zustandsbehafteter Weise durchzuführen – jedoch nicht erst am Ende der Pipeline, wie es bei Collector-Instanzen der Fall ist, sondern während des Stream-Prozesses selbst, als integraler Bestandteil der Transformation. Gatherers repräsentieren damit eine neue Klasse von Intermediate Operations, die speziell für fortgeschrittene Datenflusslogik konzipiert ist.

Die grundlegende Motivation für die Einführung der Gatherers geht auf eine Einschränkung der bisherigen API im Umgang mit zusammengesetzten, mehrschrittigen oder zustandsabhängigen Operationen zurück – insbesondere im Fall von Transformationen, bei denen nicht nur ein einzelnes Element pro Input erzeugt wird, sondern eine Abfolge, Verzögerung oder Gruppierung über mehrere Input-Elemente hinweg erforderlich ist. Bisherige Werkzeuge wie map, flatMap oder peek operieren alle entweder zustandslos oder mit limitiertem Kontext. Für komplexere Fälle mussten Entwicklerinnen und Entwickler auf spezialisierte Iterator-Implementierungen oder externe Bibliotheken zurückgreifen – was dem Ziel einer deklarativen Datenflussmodellierung in Streams widerspricht.

Gatherers lösen dieses Problem durch ein neues Verarbeitungsmodell, das auf kontrollierter Zustandshaltung basiert. Ähnlich wie Collector-Instanzen definieren sie eine Reihe von Funktionen, die es ermöglichen, Elemente zu puffern, zu transformieren und zu emittieren – allerdings nicht am Ende des Streams, sondern als Teil des laufenden Datenflusses. Sie kombinieren also die konzeptionellen Stärken von Collector und mapMulti, erweitern diese jedoch um explizite Unterstützung für temporäre Zustände und flexible Emissionsstrategien. Dabei wird ein Sink verwendet, über den sich beliebige Ergebnisse an den Downstream liefern lassen – auch mehrere pro Eingabeelement oder gar verzögert.

Der Sinn dieser Erweiterung liegt nicht nur in der Expressivität, sondern auch in der Performance. Viele Anwendungsfälle wie Sliding Windows, temporale Aggregationen, Sequenzanalysen oder Transformationslogiken mit History lassen sich mit Gatherers präzise und effizient modellieren, ohne die deklarative Struktur der Pipeline aufzugeben. Entwickler erhalten damit ein Werkzeug, das Zwischenzustände und Kontextabhängigkeit innerhalb der Stream-Verarbeitung explizit erlaubt, jedoch typgesichert, kontrolliert und idiomatisch eingebettet in die bestehende API.

Lesen Sie auch

Softwareentwicklung mit Java: Flexible Datenverarbeitung mit Stream Gatherers

---

Wie man mit Java 24 Stream Gatherers und Class-File API finalisiert

In der Entwicklung eröffnet dies neue Perspektiven. Gatherers ermöglichen das Modellieren komplexer Datenflüsse mit deklarativem Charakter, ohne in imperative Kontrolllogik zurückzufallen. Sie erweitern den semantischen Raum von Streams erheblich und stellen damit einen logischen nächsten Schritt in der Evolution der Stream-Architektur dar – vergleichbar mit der Einführung von Collector oder mapMulti. Ihre Einführung zeigt, dass Java nicht nur funktionale Prinzipien integriert, sondern diese auch in Hinblick auf Zustandsmodelle, Ablaufkontrolle und Effizienz weiterentwickelt – ohne die Kompromisse, die oft mit systemnaher Optimierung einhergehen.

Praktische Beispiele mit Gatherers

Die Einführung der Gatherers bedeutet nicht nur eine neue Erweiterung der Stream-Verarbeitung, sondern seither steht auch eine Sammlung vordefinierter Gatherers bereit, die typische, bisher schwierig modellierbare Anwendungsfälle adressieren. Die vordefinierten Gatherers kombinieren deklarative Ausdruckskraft mit zustandsbehafteter Transformation und ermöglichen dadurch neue Formen der Datenstromverarbeitung – besonders bei sequenziellen, gruppierten oder sequenziell korrelierten Datenflüssen. Zu den zentralen Vertretern dieser neuen Gattung zählen windowFixed, windowSliding, fold und scan. Jeder dieser Gatherers stellt ein spezifisches Verhalten parat, das sich vorher nur mit erheblichem manuellen Aufwand oder gar außerhalb der Stream-API umsetzen ließ.

windowFixed

Der Gatherer windowFixed erlaubt es, einen Stream in gleich große, sich nicht überlappende Fenster zu unterteilen. Dies ist besonders dann relevant, wenn Daten in Blöcken weiterverarbeitet oder aggregiert werden sollen. Mit windowFixed lässt sich beispielsweise eine Liste von Ganzzahlen auf elegante Weise in Fünfergruppen aufteilen und die Summe jeder Gruppe berechnen:

List<Integer> input = IntStream.rangeClosed(1, 15).boxed().toList();

List<Integer> resultGatherer = input.stream()
   .gather(Gatherers.windowFixed(5))
   .map(window -> window.stream().reduce(0, Integer::sum))
   .toList(); // [15, 40, 65]
System.out.println("resultGatherer = " + resultGatherer);

Die Alternative ohne Gatherers sähe wie folgt aus:

List<Integer> result = new ArrayList<>();
List<Integer> window = new ArrayList<>();
for (int i : input) {
 window.add(i);
 if (window.size() == 5) {
   result.add(window.stream().reduce(0, Integer::sum));
   window.clear();
 }
}
System.out.println("result = " + result);

Der Unterschied ist deutlich: Die Gatherers-Variante ist nicht nur kompakter, sondern trennt auch klar Datenfluss und Logik, während die imperative Lösung mit Nebeneffekten und Zustandsmanagement arbeitet.

windowSliding

Ein verwandter, aber semantisch anspruchsvollerer Fall lässt sich durch windowSliding abdecken. Hierbei handelt es sich um gleitende Fenster – jedes neue Element verschiebt das Fenster um eins:

List<Integer> input = List.of(1, 2, 3, 4, 5);
List<Double> result = input.stream()
    .gather(Gatherers.windowSliding(3))
    .map(window -> window.stream().mapToInt(Integer::intValue).average().orElse(0))
    .toList(); // [2.0, 3.0, 4.0]

Der Java-Quelltext demonstriert eine Anwendung des Gatherers windowSliding(n), der im Beispiel über eine gegebene Liste von Ganzzahlen gleitende Fenster – sogenannte Sliding Windows – erzeugt. Als Datenbasis dient eine unveränderliche Liste von Ganzzahlen:

List<Integer> input = List.of(1, 2, 3, 4, 5);

Ziel der nachfolgenden Stream-Verarbeitung ist es, über jedes gleitende Fenster der Größe drei den arithmetischen Mittelwert (Durchschnitt) der enthaltenen Elemente zu berechnen. Die Methode windowSliding(3) bewirkt, dass der Datenstrom intern in überlappende Fenster aufgeteilt wird, wobei jedes Fenster drei aufeinanderfolgende Elemente enthält. Für die Liste [1, 2, 3, 4, 5] ergeben sich daraus die folgenden Fenster:

[1, 2, 3]

[2, 3, 4]

[3, 4, 5]

Innerhalb des map-Operators wird jedes dieser Fenster wiederum in einen Stream<Integer> umgewandelt, während mapToInt(Integer::intValue).average() den Durchschnittswert berechnet. Die Methode liefert einen OptionalDouble, aus dem mittels orElse(0) ein double extrahiert wird, falls das Fenster leer sein sollte (was in diesem Anwendungsfall jedoch ausgeschlossen ist, da die Fenstergröße kleiner oder gleich der Ausgangsliste ist).

Das resultierende List<Double> enthält die Durchschnittswerte der jeweils überlappenden Tripel und sieht konkret wie folgt aus:

[2.0, 3.0, 4.0]

Der deklarative Stil des Codes fördert Lesbarkeit und Verständlichkeit, während die Gatherers-API eine elegante Möglichkeit bietet, gleitende Aggregationen direkt im Stream-Kontext durchzuführen, ohne auf manuelle Fensterlogik oder imperative Schleifen zurückgreifen zu müssen.

Mögliche Optimierungen

Es lassen sich mehrere Optimierungsziele identifizieren, die sowohl die Robustheit gegen Laufzeitfehler als auch die Performance und die semantische Lesbarkeit des Codes verbessern können. Jedes dieser Ziele stellt unterschiedliche Anforderungen an die Gestaltung des Codes.

Hinsichtlich der Performanceoptimierung lässt sich feststellen, dass der beispielhafte Quellcode unnötige Objekterzeugung durch das wiederholte Anlegen temporärer Stream-Objekte innerhalb des Mappings verursacht. Insbesondere bei großen Datenmengen kann dies zu einer spürbaren Erhöhung der Garbage-Collection-Last führen. Um die Performance zu steigern, sollte man auf die wiederholte Nutzung von stream() innerhalb des Fensters verzichten und stattdessen direkt mit der von windowSliding bereitgestellten List<Integer> arbeiten. Ein alternativer Ansatz könnte wie folgt aussehen:

List<Double> result = input.stream()
    .gather(Gatherers.windowSliding(3))
    .map(window -> {
        int sum = 0;
        for (int i : window) sum += i;
        return sum / 3.0;
    })
    .toList();

In dieser Version entfällt der Overhead der internen Stream-Verarbeitung pro Fenster vollständig. Stattdessen erfolgt die Summierung direkt über eine einfache Schleife. Das reduziert nicht nur die Allokation temporärer Objekte, sondern ermöglicht der JVM, aggressive Inlining- und Loop-Unrolling-Optimierungen vorzunehmen. Zudem ist die Division durch die Fenstergröße konstant, da windowSliding(3) eine feste Fenstergröße garantiert. Sollte die Fenstergröße jedoch dynamisch variieren, ließe sich alternativ window.size() zur Laufzeit ermitteln, ohne die semantische Korrektheit zu gefährden.

Bezüglich der Lesbarkeit ist anzumerken, dass funktionale Eleganz und imperativ ausgedrückte Klarheit nicht zwangsläufig im Widerspruch stehen. Die ursprüngliche Version mit mapToInt(...).average().orElse(0) ist zwar syntaktisch kompakt, allerdings für Entwickler gegebenenfalls weniger unmittelbar verständlich, insbesondere im Hinblick auf die Behandlung des OptionalDouble. Die imperative Variante mit direkter Summierung und Division offenbart dagegen klar die zugrunde liegende Intention – die Berechnung eines Durchschnitts über drei Elemente – ohne dass ein tiefes Verständnis der Stream-API vorausgesetzt wird. Für Entwicklungsteams mit heterogenem Erfahrungsstand oder in Codebasen mit starkem Fokus auf Wartbarkeit ist folgende Fassung daher vorzuziehen:

List<Double> result = input.stream()
    .gather(Gatherers.windowSliding(3))
    .map(window -> {
        int sum = 0;
        for (Integer value : window) {
            sum += value;
        }
        return (double) sum / window.size();
    })
    .toList();

Diese Variante verzichtet auf potenziell verwirrende Methodenketten und drückt die Berechnung schrittweise aus. Der Code ist daher nicht nur besser verständlich, sondern auch leichter testbar, da jeder Berechnungsschritt einzeln validierbar ist. Gleichzeitig bleibt er kompakt und nutzt moderne Java-Konstrukte wie Stream.gather() auf idiomatische Weise.

Zusammengefasst zeigt sich, dass sich durch die Berücksichtigung von Robustheit, Performance und Lesbarkeit sowohl die funktionale als auch strukturelle Qualität des Codes steigern lässt. Die Wahl der konkreten Optimierung hängt dabei stets vom Anwendungskontext und den Anforderungen an Laufzeitverhalten, Fehlerbehandlung und Wartbarkeit ab.

Auf die praktische Verwendung von Streams, den Einsatz von Gatherers und weitere Konzepte gehe ich in einem folgenden Beitrag ein.

Happy Coding
Sven

(map)