As a passionate Java programmer from the very beginning, I've made it my mission to help others improve their programming skills.
I do this with articles on my blog and in Java Magazin (a German publication), with videos on my YouTube channel, and with talks at JUGs and conferences like JavaLand.
You can also find me regularly at unconferences like JCrete, JChateau, and JAlba.
On this page, you will find abstracts of my talks and links to articles, talks, and interviews that I have published in other media.
In the following sections, you will find the abstracts of my conference presentations.
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).
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.
Duration: 45 minutes
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.
Duration: 40 minutes
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.
Duration: 40 minutes
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.
Duration: 40 minutes