Passionate Java Speaker

2 + 2 equals 5. And a string literal changes its content – not in one place, but everywhere in the program. Both are possible in Java, using deep reflection: setAccessible(true) and overwriting final fields.

What looks like a party trick is a serious risk to runtime integrity. Core invariants can be subverted, security assumptions broken, seemingly immutable objects manipulated – and that is exactly what makes deep reflection an attractive tool for attackers.

But even without malicious intent, it gets expensive: constant folding, one of the most fundamental JVM optimizations, only works if a value truly stays constant.

We won’t just look at this danger in theory, but in very concrete terms. Through live coding, I’ll show how deep reflection can be used to change internal state – and how an attacker can use it to subvert security assumptions.

This is exactly where JEP 500, “Prepare to Make Final Mean Final,” comes in. The JVM warns when code overwrites a final field via deep reflection; in a future version, it will throw an exception. Deep reflection thus loses its most destructive capability – at least where integrity matters more than maximum flexibility. You’ll see live how the same attacks are exposed on a modern Java version – and how to prevent them.

Finally, we’ll connect the dots to “Integrity by Default” – the next step of a plan Java has been pursuing since the module system arrived in version 9.

Java 25 introduces a fundamental change to the memory layout of objects: Compact Object Headers. In this talk, you’ll learn – supported by numerous illustrations – what this feature is all about.

We’ll use Compact Object Headers as a starting point to explore the world of object headers, object pointers, and class pointers: What exactly are OOPs (ordinary object pointers), and how do compressed OOPs work on 64-bit systems? How are traditional 128-bit object headers structured – and how can they be reduced to 96 or even 64 bits?

You’ll discover what the Mark Word is, how it’s structured, what role it plays in locking – and how that relates to the pinning of Virtual Threads. We’ll take a look at the evolution from legacy locking to lightweight locking – and how this progression paved the way for header reduction through Project Lilliput.

And last but not least, you’ll find out why smaller objects not only save memory, but can also significantly boost your application’s performance.

This talk is for developers who not only work with Java, but also want to understand the JVM mechanisms under the hood.

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.

The older and larger an application becomes, the more complex and expensive it is to extend and maintain. The widely used layered architecture is insufficient as a solution: Direct and indirect dependencies from all layers to the database and other infrastructure components often lead to blurred layer boundaries and a tight coupling of technical and business code.

Hexagonal architecture places business logic at the center and isolates technical details behind interfaces (ports) using adapters. This allows business and technical code to be developed and tested independently of each other.

Starting with the goals of a software architecture and a critical look at layered architecture, we take an in-depth look at hexagonal architecture. You’ll learn how the Dependency Rule ensures that there are no dependencies from business code to technical code—and how the application core can still access infrastructure. Does hexagonal architecture fulfill the goals of a software architecture? What challenges does it bring? How does it differ from Onion and Clean Architecture, and what synergies emerge when combined with microservices and Domain-Driven Design?

Armed with new knowledge, you’ll be able to improve the quality and longevity of your software projects and respond more quickly to new requirements in the future.

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.

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.