https://speakerdeck.com/svenwoltmann 2025-04-03 15:15:19 -0400 The Java Stream API was introduced with Java 8 in March 2014, providing us with an indispensable tool for data processing. However, the limited set of intermediate operations – `filter`, `map`, `flatMap`, `mapMulti`, `distinct`, `sorted`, `peak`, `limit`, `skip`, `takeWhile`, and `dropWhile` – means that more complex data transformations cannot be expressed directly through the Stream API. Operations like window and fold, among many others, are missing if we look at the community's feature requests. Instead of integrating all these operations into the Stream interface, the JDK team developed a new API that, on the one hand, is used within the JDK itself to provide highly requested intermediate operations and, on the other hand, allows developers to implement their own operations. This new API is called "Stream Gatherers" and was first released as a preview feature (JEP 461) in Java 22 in March 2024, exactly ten years after the introduction of the Stream API. In Java 23, the new API was sent into a second preview round without changes (JEP 473), and in Java 24, it was finalized – again without changes (JEP 485). In this talk, you will learn in theory and practice (including live coding) what Stream Gatherers are and how they work, which Gatherers are already available in the JDK and how to use them effectively, how to implement your own Gatherers, and where the limits of the new API lie. The Java Stream API was introduced with Java 8 in March 2014, providing us with an indispensable tool for data processing. However, the limited set of intermediate operations – `filter`, `map`, `flatMap`, `mapMulti`, `distinct`, `sorted`, `peak`, `limit`, `skip`, `takeWhile`, and `dropWhile` – means that more complex data transformations cannot be expressed directly through the Stream API. Operations like window and fold, among many others, are missing if we look at the community's feature requests. Instead of integrating all these operations into the Stream interface, the JDK team developed a new API that, on the one hand, is used within the JDK itself to provide highly requested intermediate operations and, on the other hand, allows developers to implement their own operations. This new API is called "Stream Gatherers" and was first released as a preview feature (JEP 461) in Java 22 in March 2024, exactly ten years after the introduction of the Stream API. In Java 23, the new API was sent into a second preview round without changes (JEP 473), and in Java 24, it was finalized – again without changes (JEP 485). In this talk, you will learn in theory and practice (including live coding) what Stream Gatherers are and how they work, which Gatherers are already available in the JDK and how to use them effectively, how to implement your own Gatherers, and where the limits of the new API lie. Mon, 31 Mar 2025 00:00:00 -0400 https://speakerdeck.com/svenwoltmann/stream-gatherers-write-your-own-stream-operations https://speakerdeck.com/svenwoltmann/stream-gatherers-write-your-own-stream-operations Die Java-Stream-API wurde mit Java 8 im März 2014 veröffentlicht und hat uns ein unverzichtbares Werkzeug an die Hand gegeben, um Daten zu verarbeiten. Doch der begrenzte Satz an intermediären Operationen – `filter`, `map`, `flatMap`, `mapMulti`, `distinct`, `sorted`, `peak`, `limit`, `skip`, `takeWhile` und `dropWhile` – führt dazu, dass komplexere Datentransformationen durch die Stream-API nicht ausgedrückt werden können. Es fehlen z. B. Operationen wie `window` und `fold` und zahlreiche mehr, wenn man sich die Feature-Requests der Community ansieht. Anstatt nun all diese Operationen ins Stream-Interface zu integrieren, entwickelte das JDK-Team eine neue API, die zum einen im JDK selbst genutzt wird, um heiß begehrte intermediäre Operationen bereitzustellen, und mit der zum anderen Entwicklerinnen und Entwickler ihre eigenen Operationen implementieren können. Diese neue API heißt „Stream Gatherers“ und wurde in Java 22 im März 2024, also genau zehn Jahre nach der Einführung der Stream-API, zum ersten mal als Preview-Feature (JEP 461) veröffentlicht. In Java 23 wurde die neue API ohne Änderungen in eine zweite Preview-Runde geschickt (JEP 473), und in Java 24 wurde sie – wieder ohne Änderungen – finalisiert (JEP 485). In diesem Talk erfahrt ihr in Theorie und Praxis (inklusive Live-Coding), was Stream Gatherers sind und wie sie funktionieren, welche Gatherer im JDK bereits verfügbar sind und wie ihr sie effektiv einsetzt, wie ihr selbst eigene Gatherer implementieren könnt und wo die Grenzen der neuen API liegen. Die Java-Stream-API wurde mit Java 8 im März 2014 veröffentlicht und hat uns ein unverzichtbares Werkzeug an die Hand gegeben, um Daten zu verarbeiten. Doch der begrenzte Satz an intermediären Operationen – `filter`, `map`, `flatMap`, `mapMulti`, `distinct`, `sorted`, `peak`, `limit`, `skip`, `takeWhile` und `dropWhile` – führt dazu, dass komplexere Datentransformationen durch die Stream-API nicht ausgedrückt werden können. Es fehlen z. B. Operationen wie `window` und `fold` und zahlreiche mehr, wenn man sich die Feature-Requests der Community ansieht. Anstatt nun all diese Operationen ins Stream-Interface zu integrieren, entwickelte das JDK-Team eine neue API, die zum einen im JDK selbst genutzt wird, um heiß begehrte intermediäre Operationen bereitzustellen, und mit der zum anderen Entwicklerinnen und Entwickler ihre eigenen Operationen implementieren können. Diese neue API heißt „Stream Gatherers“ und wurde in Java 22 im März 2024, also genau zehn Jahre nach der Einführung der Stream-API, zum ersten mal als Preview-Feature (JEP 461) veröffentlicht. In Java 23 wurde die neue API ohne Änderungen in eine zweite Preview-Runde geschickt (JEP 473), und in Java 24 wurde sie – wieder ohne Änderungen – finalisiert (JEP 485). In diesem Talk erfahrt ihr in Theorie und Praxis (inklusive Live-Coding), was Stream Gatherers sind und wie sie funktionieren, welche Gatherer im JDK bereits verfügbar sind und wie ihr sie effektiv einsetzt, wie ihr selbst eigene Gatherer implementieren könnt und wo die Grenzen der neuen API liegen. Mon, 31 Mar 2025 00:00:00 -0400 https://speakerdeck.com/svenwoltmann/stream-gatherers-schreibe-deine-eigenen-stream-operationen https://speakerdeck.com/svenwoltmann/stream-gatherers-schreibe-deine-eigenen-stream-operationen We all know this situation: the older and larger an application gets, the more complex and expensive it becomes to expand and maintain it. The widespread layered architecture is inadequate as a solution approach: direct and indirect dependencies of all layers on the database and other infrastructure components often lead to a blurring of the layer boundaries and an interweaving of technical and functional code. Hexagonal architecture places the business logic at the center, and technical details are isolated as adapters behind interfaces (ports). Business and technical code can thus be developed and tested independently of each other. Based on the objectives of a software architecture and a critical look at the layered architecture, we take a detailed look at the hexagonal architecture. You will learn how the dependency rule ensures that there are no dependencies between functional and technical code and how the application core can still access the infrastructure. Does the hexagonal architecture fulfill the goals of a software architecture? What challenges does it bring with it? How does it differ from onion and clean architecture, and what synergies arise in interaction with microservices and domain-driven design? Equipped with new knowledge, you can increase the quality and lifespan of your software projects and react more quickly to new requirements in the future. We all know this situation: the older and larger an application gets, the more complex and expensive it becomes to expand and maintain it. The widespread layered architecture is inadequate as a solution approach: direct and indirect dependencies of all layers on the database and other infrastructure components often lead to a blurring of the layer boundaries and an interweaving of technical and functional code. Hexagonal architecture places the business logic at the center, and technical details are isolated as adapters behind interfaces (ports). Business and technical code can thus be developed and tested independently of each other. Based on the objectives of a software architecture and a critical look at the layered architecture, we take a detailed look at the hexagonal architecture. You will learn how the dependency rule ensures that there are no dependencies between functional and technical code and how the application core can still access the infrastructure. Does the hexagonal architecture fulfill the goals of a software architecture? What challenges does it bring with it? How does it differ from onion and clean architecture, and what synergies arise in interaction with microservices and domain-driven design? Equipped with new knowledge, you can increase the quality and lifespan of your software projects and react more quickly to new requirements in the future. Sun, 07 Apr 2024 00:00:00 -0400 https://speakerdeck.com/svenwoltmann/hexagonal-architecture-robust-software-with-interfaces-instead-of-layers https://speakerdeck.com/svenwoltmann/hexagonal-architecture-robust-software-with-interfaces-instead-of-layers Wir alle kennen diese Situation: Je älter und größer eine Anwendung wird, desto aufwendiger und teurer wird es, sie zu erweitern und zu warten. Die verbreitete Schichtenarchitektur ist als Lösungsansatz unzureichend: Direkte und indirekte Abhängigkeiten aller Schichten zur Datenbank und anderen Infrastrukturkomponenten führen oft zu einer Aufweichung der Schichtengrenzen und einer Verflechtung von technischem und fachlichem Code. Hexagonale Architektur rückt die Geschäftslogik ins Zentrum, und technische Details werden als Adapter hinter Schnittstellen (Ports) isoliert. Fachlicher und technischer Code kann so unabhängig voneinander entwickelt und getestet werden. Ausgehend von den Zielen einer Softwarearchitektur und einem kritischen Blick auf die Schichtenarchitektur, schauen wir uns die hexagonale Architektur im Detail an. Ihr erfahrt, wie die Dependency Rule sicherstellt, dass es keine Abhängigkeiten von fachlichem zu technischem Code gibt und wie der Anwendungskern trotzdem auf die Infrastruktur zugreifen kann. Erfüllt die hexagonale Architektur die Ziele einer Softwarearchitektur? Welche Herausforderungen bringt sie mit sich? Wie unterscheidet sie sich von Onion und Clean Architecture, und welche Synergien ergeben sich im Zusammenspiel mit Microservices und Domain-Driven Design? Mit neuem Wissen gerüstet, könnt ihr die Qualität und Lebensdauer eurer Softwareprojekte steigern und in Zukunft schneller auf neue Anforderungen reagieren. Wir alle kennen diese Situation: Je älter und größer eine Anwendung wird, desto aufwendiger und teurer wird es, sie zu erweitern und zu warten. Die verbreitete Schichtenarchitektur ist als Lösungsansatz unzureichend: Direkte und indirekte Abhängigkeiten aller Schichten zur Datenbank und anderen Infrastrukturkomponenten führen oft zu einer Aufweichung der Schichtengrenzen und einer Verflechtung von technischem und fachlichem Code. Hexagonale Architektur rückt die Geschäftslogik ins Zentrum, und technische Details werden als Adapter hinter Schnittstellen (Ports) isoliert. Fachlicher und technischer Code kann so unabhängig voneinander entwickelt und getestet werden. Ausgehend von den Zielen einer Softwarearchitektur und einem kritischen Blick auf die Schichtenarchitektur, schauen wir uns die hexagonale Architektur im Detail an. Ihr erfahrt, wie die Dependency Rule sicherstellt, dass es keine Abhängigkeiten von fachlichem zu technischem Code gibt und wie der Anwendungskern trotzdem auf die Infrastruktur zugreifen kann. Erfüllt die hexagonale Architektur die Ziele einer Softwarearchitektur? Welche Herausforderungen bringt sie mit sich? Wie unterscheidet sie sich von Onion und Clean Architecture, und welche Synergien ergeben sich im Zusammenspiel mit Microservices und Domain-Driven Design? Mit neuem Wissen gerüstet, könnt ihr die Qualität und Lebensdauer eurer Softwareprojekte steigern und in Zukunft schneller auf neue Anforderungen reagieren. Sun, 07 Apr 2024 00:00:00 -0400 https://speakerdeck.com/svenwoltmann/hexagonale-architektur-robuste-software-dank-schnittstellen-statt-schichten https://speakerdeck.com/svenwoltmann/hexagonale-architektur-robuste-software-dank-schnittstellen-statt-schichten The coordination of concurrent, potentially blocking subtasks quickly reaches its limits with classic approaches such as CompletableFuture and ExecutorService. For example, canceling subtasks, whether after error situations or if we only need the result of a subtask, quickly leads to confusing interdependencies between business logic and state handling. We then speak of “unstructured concurrency”. With StructuredTaskScope, we now have an API for “structured concurrency” that allows us to start and end subtasks together, merge the results, and, if necessary, cancel subtasks cleanly. Using practical examples, I will show you that only a few easy-to-understand lines of code are needed for most use cases thanks to predefined strategies such as “all subtasks must be successful” and “abort if one subtask is successful.” You can also handle individual requirements cleanly with StructuredTaskScope – I’ll show you an example of how to implement a strategy that waits for a certain number of partial results and then returns the best result. The coordination of concurrent, potentially blocking subtasks quickly reaches its limits with classic approaches such as CompletableFuture and ExecutorService. For example, canceling subtasks, whether after error situations or if we only need the result of a subtask, quickly leads to confusing interdependencies between business logic and state handling. We then speak of “unstructured concurrency”. With StructuredTaskScope, we now have an API for “structured concurrency” that allows us to start and end subtasks together, merge the results, and, if necessary, cancel subtasks cleanly. Using practical examples, I will show you that only a few easy-to-understand lines of code are needed for most use cases thanks to predefined strategies such as “all subtasks must be successful” and “abort if one subtask is successful.” You can also handle individual requirements cleanly with StructuredTaskScope – I’ll show you an example of how to implement a strategy that waits for a certain number of partial results and then returns the best result. Tue, 19 Sep 2023 00:00:00 -0400 https://speakerdeck.com/svenwoltmann/concurrency-made-easy-structured-concurrency-and-scoped-values-in-action https://speakerdeck.com/svenwoltmann/concurrency-made-easy-structured-concurrency-and-scoped-values-in-action Threads, which have always been an integral part of Java, have their limits: You cannot start more than a few thousand without jeopardizing system stability. For highly scalable applications, we had to resort to asynchronous programming. But asynchronous code is difficult to write, read and debug. For years, a pioneering solution was being worked on within Project Loom: With almost 100,000 changed lines of code, the final version of virtual threads finally appeared in Java 21. These require orders of magnitude fewer resources than conventional threads, especially for blocking operations. Instead of thousands, we now have millions of threads at our disposal. This allows us to write highly scalable applications in the traditional thread-per-request style that are easier to maintain, test, and debug than asynchronous applications. Using an example application, I will take you from the limitations of classic concurrent programming to asynchronous approaches and the possible applications and functionality of virtual threads. With a final overview of limitations and potential pitfalls, as well as some tips on migrating existing applications, you will be well-equipped to use virtual threads in your daily work. Threads, which have always been an integral part of Java, have their limits: You cannot start more than a few thousand without jeopardizing system stability. For highly scalable applications, we had to resort to asynchronous programming. But asynchronous code is difficult to write, read and debug. For years, a pioneering solution was being worked on within Project Loom: With almost 100,000 changed lines of code, the final version of virtual threads finally appeared in Java 21. These require orders of magnitude fewer resources than conventional threads, especially for blocking operations. Instead of thousands, we now have millions of threads at our disposal. This allows us to write highly scalable applications in the traditional thread-per-request style that are easier to maintain, test, and debug than asynchronous applications. Using an example application, I will take you from the limitations of classic concurrent programming to asynchronous approaches and the possible applications and functionality of virtual threads. With a final overview of limitations and potential pitfalls, as well as some tips on migrating existing applications, you will be well-equipped to use virtual threads in your daily work. Tue, 19 Sep 2023 00:00:00 -0400 https://speakerdeck.com/svenwoltmann/virtual-threads-project-looms-scalability-revolution https://speakerdeck.com/svenwoltmann/virtual-threads-project-looms-scalability-revolution