In my previous blog post I started an experiment with using Project Loom. The post outlined the first steps to make use of virtual Threads on a best-effort basis (i.e., without rewriting the entire libraries involved, instead fixing issue by issue until it works™).

This article walks you through a experiment that uses a Spring Boot application with Virtual Threads. Having access to early access builds is the perfect opportunity to take a look what it takes to use virtual threads as worker threads. With all customizations in place, we issue a few request to verify that our application is running. Finally, we put a bit of load onto the application to see how memory consumption and the number of kernel threads develop over time.

Follow-up post: Carrier Kernel Thread Pinning of Virtual Threads (Project Loom).

This blog post explains the motivation behind removing Project Lombok from one of the projects to which I contribute. It reflects my personal opinion and is not discouraging particular technologies.

About three years ago, I got to know Project Lombok, a library that spices up Java code. I liked it from the beginning as it contributes so much useful functionality. I work a lot with entities (data classes) and value objects, so it does not come as a surprise that @Data or Kotlins data class are very convenient. You get more bang for the buck – literally.
I’m mentioning Kotlin here because it shares some of the properties that we also get from Lombok.

Spring Framework announced recently to ship with support for reactive transaction management.
Let’s take an in-depth look at how this works for R2DBC, the reactive specification for SQL database access.