February - The Rest of the Story - JVM Weekly vol. 119
Since the last few editions have been quite thematic, I’ve gathered many interesting links in February that didn’t make it into previous issues. Many aren’t extensive enough for a full section, but they still seem compelling enough to share.
And to wrap things up, I’m adding a few release updates.
A week ago, I focused on Scala, so let’s kick off our little review with that language.
I have some exciting news shared by Tomasz Godzik : the upcoming LTS version of Scala 3, planned for the fourth quarter of 2025, will say goodbye to JDK 8. The Scala team is now considering whether the minimum requirement will be JDK 11 or 17. The main reason for this change is the planned removal of memory access methods in sun.misc.Unsafe in future JDK versions, which requires modifications to the lazy val implementation in Scala.
Moving to a newer JDK will open the door to utilizing new features and improvements in the standard library, such as access to private members between related classes or new bytecode shapes for pattern matching.
The next article I’d like to share is a review of questions (and answers!) from a job interview at J.P. Morgan for the position of Java Lead - shared by Shivam Srivastava - which also serves as a solid cheat sheet for modern Spring, microservices, and advanced Java 8 topics.
The article covers topics like content negotiation (how to agree on data formats), the differences between regular and "injected" beans, best practices for designing the DAO layer, and ways to secure microservices. There’s also discussion about MongoDB performance, the consistency of hashCode() and equals(), and even "magic" with WeakHashMap (a classic).
In other words, if you’re preparing for a Java interview, this material is full of interesting, non-obvious questions. Too bad it’s behind Medium’s paywall, if only there were a tool to handle that...
Now, we have a true "Rest of the Story." A few editions ago, I had the chance to talk about how Ioannis Anifantakis was slowly working through the principles of SOLID in Kotlin. Since then, a few weeks have passed, and Ioannis, being a prolific author, has completed the series and also dived into several other Kotlin-related topics, such as Interfaces vs Abstract Classes in Java and Kotlin or the latest Kotlin inline reified to Solve Type Erasure, and a Practical Guide on noinline, crossinline, and More.
I highly recommend these, they’re useful materials.
Next up is a super interesting draft JEP. These usually make it into regular reviews, but Ahead-of-time Command Line Ergonomics was such a wildcard that it didn’t quite fit into any edition so far.
The JEP simplifies the process of creating AOT caches. Currently, it requires two steps: first running the application with the -XX:AOTMode=record option (to gather dynamic data), and then with -XX:AOTMode=create to create the actual AOT cache. The proposed change allows this to be done in one step, by running the application with the default AOT mode and a new flag -XX:AOTCacheOutput=myapp.aot. This will automatically train and create the AOT cache once the application finishes running, eliminating the need to manage temporary configuration files.
It’s a small thing, but it’s great, especially if you want to squeeze the maximum performance from our builds.
And that’s not the end of performance-related topics. Nicolas Toper, in his article A proof of concept of a JVM autoparallelizer, presents the concept of automatic loop parallelization in compiled Java bytecode. His tool analyzes bytecode, identifies loops, assesses their safety for parallel execution, and then modifies the code to add parallel versions.
In tests, the tool achieved a 9x speedup for large loops without needing to modify the source code. Furthermore, the tool dynamically decides whether parallelization is worthwhile, avoiding overhead in the case of small loops. This approach differs from traditional High-Performance Computing tools because it operates at the bytecode level and doesn’t require static arrays or known loop boundaries.
Although it’s an early-stage project, the results presented by the author are promising, and I’ll certainly keep an eye on it.
What would a month be without some articles at the intersection of Java and Foundational Models?
In the second part of the series Agentic AI with Quarkus, Mario Fusco delves into the topic of AI agents, building on the first part, which we’ve already mentioned. The patterns presented in the second part differ from the ones discussed earlier in that the control flow is fully delegated to the LLM, giving the agent greater flexibility and autonomy.
In Quarkus, agents are represented by interfaces with the @RegisterAiService annotation, and the methods of these interfaces can be equipped with a set of tools (@ToolBox) that the LLM can use to accomplish tasks. This approach allows for dynamic and intelligent task management by the LLM, significantly simplifying the creation of advanced AI applications.
The example presented is a weather forecasting agent that analyzes user queries, identifies the city name, retrieves its geographical coordinates, and then provides the current forecast.
Any Raspberry Pi enthusiasts here?
If so, I have great news: Pi4J, a library that gives Java developers easy access to the full I/O capabilities of Raspberry Pi – sensors and pins – now requires Java 21 due to support for new platform features.
For those who aren’t familiar with the project, Pi4J offers a friendly, object-oriented API that simplifies interaction with electronic components via various interfaces such as GPIO, I2C, and SPI.
Finally: In the past, I mentioned that Azul is closely monitoring regulatory topics. Now the company has announced full compliance of its OpenJDK solutions with the European Digital Operational Resilience Act (DORA).
This means that their platform not only meets regulatory standards but also strengthens digital resilience and minimizes risks. This allows European financial institutions to add another item to their checklist – and I’m saying this without any sarcasm. In my opinion, it’s a great move by the company and a real step toward addressing client issues.
Release Radar
Very Kotlin-centric – but no spoilers or delays.
KotlinPoet 2.0
KotlinPoet is a library from Square that helps generate Kotlin source code. With KotlinPoet, developers can automatically generate code, eliminating the need for manually writing repetitive parts and ensuring consistency with metadata. KotlinPoet is inspired by the earlier JavaPoet library, adapting its functionalities to Kotlin’s specifics, enabling easy definition of classes, functions, properties, and other elements of the language. It is particularly useful in annotation processing and when interacting with metadata files such as database schemas or protocol formats.
Recently, KotlinPoet 2.0 was released, maintaining binary compatibility with the 1.x series, so migration should be smooth. The main change is the handling of spaces during code generation. In previous versions, long lines were automatically broken, which sometimes led to compilation errors. Now, spaces are no longer broken by default, and introducing the ♢ symbol allows developers to indicate where line breaks are safe.
That’s it, but *Poet is always worth mentioning.
Dokka 2.0
Dokka, the tool for generating Kotlin code documentation, has just released version 2.0.0. This introduces elegant configuration thanks to the brand-new Dokka Gradle Plugin v2 based on Dokkatoo, which brings typical Gradle improvements such as better performance and readability thanks to a declarative DSL. Also on the table is the experimental K2 analysis, promising compatibility with future language features (although it requires a little patience due to some minor issues with limitations and rendering differences). Additionally, all this is wrapped in a refreshed HTML format that cares about accessibility and ease of customization. Since we co-created the original Dokka in the VirtusLab , I’m personally excited about easier integration and more transparent documentation. Although I admit that the new (heavily changed) configuration may initially cause some bewildered smiles – but sometimes it’s good to stumble a bit before you can fly, right?
Pulumi for Java 1.0
Pulumi is an Infrastructure as Code (IaC) platform that allows defining and managing cloud resources using popular programming languages like TypeScript, Python, Go, or C#, and now even Java (I’m sure you know where this is going, right?).
With Pulumi Java 1.0, you can model infrastructure using the builder pattern, meaning you can compose resources with strong typing and readable, declarative code. The biggest novelty in this version is the Java Automation API, which allows you to not only define infrastructure but also programmatically orchestrate entire Pulumi projects. The Automation API provides direct access to project and stack objects, enabling installation of plugins, setting configurations, and initiating deployments directly from Java code.
Self-plug – Pulumi was also co-created by VirtusLab , specifically by Paweł Prażak . Great job Paweł.
Ktor CLI
Anyone who uses Kotlin is probably familiar with Ktor – one of the most popular frameworks for creating backend applications, known for its lightweight, asynchronous nature and tight integration with Kotlin.
Recently, the team behind it released the Ktor CLI – a command-line tool to help create projects. With just one command, you can generate the skeleton of a new application, and all this without unnecessary fuss. Written in Go (😨), Ktor CLI offers commands like ktor new for quick starts, ktor openapi for generating projects from OpenAPI files, or ktor add to easily add dependencies to existing projects. Additionally, the developer mode (ktor dev) allows development without the need for continuous restarts.
CheerpJ 3.1
Our last hero, CheerpJ, is a bold attempt to embed a fully functional JVM into WebAssembly and prove that Java can settle in the browser just as well as JavaScript (or even better!).
The latest version 3.1 primarily stabilizes the new architecture with a JIT compiler, making applications and applets run faster and compatible with most of the Java code circulating in the ecosystem. A long list of bugs has been fixed, support for audio has been added, and we’re approaching the epic release of CheerpJ 4.0, which promises support for Java 11+, JNI modules, and (watch out, Minecraft fans) the possibility to run the game in the browser.
All this confirms that CheerpJ is heading toward making Java a full-fledged citizen of the WebAssembly world – I personally can’t wait to see how large Java applications run in the browser and whether we can finally make a decent version of Minecraft in Chrome.
No matter how it goes, I’m rooting for the Leaning Technologies team – their determination might be the key that opens the door to Java on the internet again.
PS1: Follow-up on Ktor-CLI – some predictions come true quickly. The circle of hatred has already started.
PS2: Today in Poland it's Fat Thursday, the best holiday ever. Let's celebrate with us and eat some tasty doughnuts!
PS3: I "borrowed" the title The Rest of the Story from Planet Money, which they took from Paul Harvey, the legendary American radio broadcaster. I’ve always liked it 😃.