March - The Rest of the Story - JVM Weekly vol. 123
Since the last few editions have been quite thematic, I’ve gathered many interesting links in March 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.
1. Missed in March
Last week, the official Oracle conference dedicated to Java – JavaOne 2025 – took place. Apart from the talks (which I hope we’ll see soon) and the release of the new JDK/GraalVM, something was presented that has a good chance of shaking up the world of beginner developers: a new educational initiative called learn.java.
It’s largely based on materials previously available at dev.java, but on learn.java students and teachers each get their own "Corner" to develop their skills, and more advanced users can look into sections with new features like Records and Pattern Matching. The aim is to create a space that provides simple explanations, educational materials, and ready-made solutions — without drifting into long-winded theorizing.
It sounds like an answer to the eternal question "Where to start learning Java?", which I regularly get (and for which I’m preparing a special resource — just want to do it really well, so it takes time, Valhalla style). You could say that Oracle (with community support) has just prepared such an entryway into this world, shortening the distance between students and the compiler. Nicely coinciding with the initiative to simplify the entire “ceremony,” which we’ve seen in the latest JDK releases.
Still on the subject of JavaOne 2025, Adam Bien shared a brief note with his impressions of the conference. TL;DR: JavaOne definitely “delivered,” both in terms of organization and the quality of presentations. Perhaps the most interesting piece of information is the fact that over 70% of guests showed up at the conference for the first time. The only small downsides? Sometimes the room was too big, sometimes a bit too small, and there were no evening BoFs - Birds of a Feather, informal meetups of participants focused on specific topics.
This month, Tech Talks Weekly served up a solid feast for all Java “maniacs” (and I’m deliberately using the word “maniacs” here) — a list of the 100 most-watched Java presentations of 2024. If you’ve ever made the decision that your watch queue is already too long and you’re not adding anything else, you’ll quickly change your mind after looking at this ranking.
The Hibernate team announced on March 14 that Hibernate ORM was successfully relicensed to the Apache License 2.0, aiming to increase acceptance among Apache/Jakarta projects and other communities that previously avoided LGPL.
However, as a result of this process, some modules, such as hibernate-envers, were temporarily removed from the main repository because certain contributors did not agree to change the license. For example, the hibernate-envers code was moved to a temporary repository, retaining the entire commit history.
Switching to the Apache 2.0 license opens the door to broader collaboration, as it’s one of the most widely accepted licenses in large organizations and open-source projects. This facilitates easier integration of Hibernate with other libraries, eliminating concerns related to LGPL.
In times when the world is undergoing surprisingly fast “decoupling” (to put it mildly), RISC-V— an open standard for CPU architecture — continues to gain greater attention, which also impacts JVM projects. Java just joined the party once again, as announced by the Juan Fumero TornadoVM latest research, which leverages RISC-V vector extensions to accelerate running Java code on that platform through the oneAPI Construction Kit, has been accepted for publication at RISC-V Summit Europe 2025.
How does it work in practice? TornadoVM translates bytecode to OpenCL and SPIR-V in the first stage, and then oneAPI Construction Kit turns it into an optimized binary capable of squeezing the maximum performance out of RISC-V. The results are really impressive—during matrix tests, they achieved up to a 33x performance increase compared to single-threaded Java and a 4.6x increase compared to multi-threaded Java.
Gradle is finally addressing what users painfully feel with every major migration: deprecations, API changes, and all that manual tweaking of builds.
Or at least addressing what #TeamMaven always points to: that the build should be boring.
The newest proposal by Rafael Chavez is to integrate OpenRewrite by Moderne, a more-than-once mentioned here tool that, thanks to "recipes", automatically refactors code fragments. OpenRewrite would respond to the breaking changes and deprecations appearing in subsequent Gradle versions (initially focusing mainly on the Provider API). The plan is to provide “official” recipes for each new version of Gradle, which can be run using a separate plugin. This means developers will have less tedious, manual tinkering and the assurance that after moving to the latest version, the build still works (and maybe even runs faster?
Does anyone still remember Heroku?
The platform that for years was synonymous with simplicity in deploying applications is once again making itself known—this time with refreshed support for Java and its most popular frameworks: Spring Boot, Quarkus, and Micronaut.
The new feature is full integration with Paketo Buildpacks, which provide support for Java 21+. Buildpacks are, in practice, a set of automated steps that detect the technology stack and configure the environment so that the application simply works. In short: you throw in your code, and Heroku — thanks to the buildpack system — automatically detects the project type, picks the right tools, sets ports, environment variables (like PORT or SPRING_PROFILES_ACTIVE), and starts the application without having to write a Procfile or do manual configuration.
Powertools for AWS Lambda is a set of lightweight open-source libraries created by AWS and the community, which simplify the implementation of serverless best practices. Each “PowerTool” is a separate module (for example, for logging, collecting metrics, tracing, schema validation, or feature flags) that you can include independently, but all are designed with minimal dependency injection, compliance with the AWS Well-Architected Framework, and easy integration into existing Lambda code. Thanks to PowerTools, you don’t have to manually configure OpenTelemetry, CloudWatch Logs, or the JSON structure for metrics—everything is ready, without unnecessary “glue.”
The Powertools for AWS Lambda Java team presented the project’s roadmap and announced they’re preparing to make a grand entrance with version 2.0—with a robustly secured release process, a strong emphasis on consistency of core utilities, and a long-term plan for feature parity with solutions in other languages, primarily utilities such as logging, metrics, and tracing. They also plan to drop support for Java 8 (time at last to move on to Java 11) and introduce GraalVM and CRaC support (so all fans of Lambda Snapstart have even fewer reasons to complain about cold starts).
As a bonus, there’s also integration with popular frameworks (Micronaut, Quarkus, Spring Cloud Function), and in the queue, they have additional modules like S3 Streaming or Feature Flags.
And since we’re already talking about roadmaps, I have one more for you. Kotlin team has published theirs.
At the same time, there’s no room for boredom: they start by deprecating the old K1 compiler (it served long and faithfully, but time moves on), while also polishing up JSpecify support and pushing Kotlin/Wasm to Beta (wasm-js).
On the multiplatform front, a first public release of Swift Export is in the works and an even better garbage collector (CMS) becomes the default. Anyone who complained about complicated klib configurations can get ready for major simplifications.
As for the broader ecosystem, Ktor is getting a plugin for gRPC (plus HTTP/3 support), and Exposed is finally on its way to 1.0, adding R2DBC support. Add to that ongoing Gradle integration work, better import results in IntelliJ, and a more refined Kotlin Notebook—and in short, JetBrains reminds us why Kotlin remains one of the most dynamic and enjoyable languages on the JVM (and beyond).
And with that note, we smoothly transition to the Release Radar.
2. Release Radar
Kotlin 2.1.20
Besides the roadmap, Kotlin 2.1.20 was also published, effectively the final preparations for version 2.2… which is evident. First, the K2 compiler is moving forward aggressively: we have a new version of kapt that is now default in K2 (but can be disabled for now if something goes wrong), plus better support for Lombok (especially @SuperBuilder).
On the multiplatform front, Kotlin gives us a brand-new DSL that’s intended to replace the existing Gradle plugins like “Application,” as well as improvements in Kotlin/Wasm (including DWARF debugging support and automatic custom formatters in development builds). All this is accompanied by fresh changes in Kotlin/Native, introducing a new “inlining pass” for better performance.
The second pillar of this update involves work on the standard library. In short: we now have a set of experimental atomic types (AtomicInt, AtomicLong, etc.), which finally allows avoiding external dependencies in multiplatform projects. Also, Kotlin is refining UUID handling even more (now you can compare them like regular numbers). Topping it all off is moving some time functions (Clock and Instant) directly into the standard library. This means that if you’ve been using kotlinx-datetime just to get the “current moment in time,” you can now do so in the Kotlin time package—simpler but still precise.
For a final flourish, there are plenty of smaller improvements: the Compose compiler removes restrictions on default arguments in open @Composable functions, and Gradle gets a few experimental features (like Isolated Projects or custom variants). The Kotlin documentation has also seen some cleaning up, plus new sections (e.g., a comparison with Flutter or an updated roadmap).
It’s fair to say that Kotlin 2.1.20 is a release in which JetBrains embraces a number of experiments and shows us the direction it plans to take in the coming months.
JavaFX 24
JavaFX 24 hits the scene with significant changes, including a requirement to use at least JDK 22 (targeting 24), a need to explicitly enable native access (--enable-native-access) in the context of JEP 472, the inclusion of the jdk.jsobject module (now part of JavaFX, replacing the one from the JDK), and support for pluggable image loaders via javax.imageio. The ability to run with the Security Manager (which itself was completely disabled in JDK 24) has also been removed.
Among the new features on the list are, for instance, the incubating RichTextArea control, pluggable InputMap, support for @1x in image filenames, or the reducedMotion preference. These updates are complemented by a substantial set of fixes in areas such as UI, WebView, tools, and multimedia support. Additionally, ScrollPane now only responds to keyboard events when it actually has focus.
Vaading 24.7
Vaadin 24.7 is a release that simplifies the creation of business applications—focusing on automation, security, and developer convenience. Flow has gained better error resilience, native-image support for Quarkus, and easier OAuth2 logout settings. Hilla offers better file uploads, support for React 19, and stronger typing in Kotlin.
For those still on Vaadin 7 — the Modernization Toolkit has been further simplified, and Copilot works better with AI, supporting custom components. DevOps folks will appreciate the new Control Center with a log viewer, Passkey, and automatic certificate management.
The Design System, in turn, offers a new Card component, drag & drop in Gantt charts, and improvements in Grids, layouts, and accessibility. The ready-made API for Spring Data simplifies hooking up Grids and ComboBoxes. In short: less work, more automation and support—an ideal version to start modernizing or to speed up development.
P.S.: The team is conducting the survey Considerations for Java Projects in 2025. If you have a moment, fill it out—maybe they’ll come up with some interesting insights to share 😀
Apache Kafka 4.0
Listing Kafka among releases is a bit... of a stretch, but it’s big enough and strongly tied to the JDK ecosystem that I thought it was worth giving Confluent some space.
Apache Kafka 4.0 is quite a revolution: above all, the project now runs in KRaft mode by default, dropping Apache ZooKeeper and simplifying deployment and management (giving us fewer operational complexities and better scalability). Additionally, KIP-848 goes into general use, bringing a new consumer group protocol that significantly speeds up rebalances and reduces downtime in large clusters. It’s also worth noting the early version of Queues for Kafka (KIP-932), opening the possibility of using traditional message queues (point-to-point).
Aside from that, in this release, they’ve removed long-deprecated interfaces and set new minimum Java versions: Kafka Clients and Kafka Streams require JDK 11, while Kafka Brokers, Connect, and Tools require JDK 17.
Quarkus 3.19
Quarkus 3.19 arrives with a bang and heralds substantial preparation for the upcoming 3.20 LTS release.
The key novelties? First, Quarkus is abandoning its existing base images and switching to UBI 9 (Universal Base Image 9 — Red Hat’s official container image, based on RHEL 9, guaranteeing support, security patches, and compatibility with the Red Hat ecosystem). Additionally, there’s a new “bridge” for Micrometer (a popular tool for metrics gathering) that lets you send those metrics to OpenTelemetry (the standard for observability in distributed systems), and we finally get to use the Ahead-of-Time Cache compliant with JEP 483.
Add to that the automation of configuration through the @ConfigMapping annotation in all Quarkus extensions (a step toward unifying the approach to configs, which will eventually replace old config classes). The icing on the cake is “WebSockets Next” with built-in “permission checkers” (an access control mechanism) and the ability to forward Authorization headers directly from the browser, plus proof-of-possession support in OIDC (OpenID Connect), boosting security when exchanging tokens.
Gradle 8.13
Gradle 8.13 brings several significant improvements, first and foremost automatic provisioning of a compatible Java version for the Daemon JVM (so-called Daemon JVM auto-provisioning) if a suitable local installation isn’t found. This makes it easier to configure various JVMs for running Gradle itself and for building projects. This version also introduces explicit definition of the Scala version (within the Scala extension), eliminating the need to manually add a dependency on scala-library, and it provides more precise timestamps (down to milliseconds) in JUnit XML reports.
Among the improvements in build authoring, it’s worth mentioning the new artifactTransforms task for inspecting custom artifact transformations, a custom API for test reporting, and a fresh distribution-base plugin that offers the full functionality of the Distribution plugin — but without creating a default distribution.
Jakarta NoSQL 1.0
Finally, for the Jakarta EE corner, the long-awaited premiere of Jakarta NoSQL 1.0 lead by Otavio Santana arrives, introducing a unified set of interfaces and annotations. These allow Java application designers to easily and flexibly integrate with various NoSQL databases. By abstracting and standardizing operations such as object mapping, queries, or transaction management, Jakarta NoSQL significantly simplifies work on the persistence layer.
The overarching goal of the project is to increase productivity and unify approaches to NoSQL databases in the Jakarta EE ecosystem. Providing extensive object mapping, flexible configuration, and the ability to extend with custom implementations, Jakarta NoSQL makes it easier to work with various data models (document, key-value, graph, columnar) while maintaining Java’s typical code consistency. However, the project does not aim to fully replace the capabilities of all existing ORM tools or guarantee 100% compatibility with every NoSQL database. Instead, it provides a stable foundation on which to build an ecosystem of plugins and extensions, supporting both present and future data storage needs.
3. GitHub All-Stars
And now for some new, interesting projects I’ve spotted, which I hope we’ll hear more about in the future.
Bovine JVM
b-jvm (Bovine JVM) Timothy Herchen is an experimental project for running Java code in the browser via WebAssembly, without needing external porting or limiting functionality. It’s not affiliated with Oracle or OpenJDK, but it provides nearly full support for modern Java features (MethodHandle, VarHandle, invokedynamic) and correct exception handling, including, for example, ArrayStoreException.
The project is based on a C-written interpreter with a compact GC, supports “threads” through context switching (with support for Object.wait/notify or Unsafe.park), and also allows integration with JavaScript (you can call JS code and vice versa). The goal is also to implement a WebAssembly or x86/ARM64 JIT, generational GC, and various other extensions. With mechanisms like URLClassLoader or a profiler (DTrace), you can test and analyze performance in the browser without compiling the project with TeaVM or GWT/J2CL.
The creators view b-jvm as an educational platform and a way to push the boundaries of what WebAssembly offers, while making it easier for Java developers to integrate with the web.
Fray
Fray by Carnegie Mellon University is a tool for concurrency testing in Java, leveraging advanced techniques for controlled execution of multithreaded programs — such as probabilistic concurrency testing and partial order sampling.
In practice, this means that instead of relying on random luck (or lack thereof) in typical multithreaded testing, Fray provides a controlled and repeatable environment of chaos, provoking potential conflict scenarios with higher probability. As a result, it can detect hard-to-reproduce errors like assertion violations, unexpected runtime exceptions, or even deadlocks. Fray also offers deterministic replay of threads, simplifying debugging of specific problematic interleavings.
Integration is simple: the tool supports JUnit (via the @ConcurrencyTest annotation) and other testing frameworks, and it includes Gradle and Maven plugins, so you can incorporate it into your existing build and testing process.
JDBG
JDBG by roger1337 is an advanced tool for debugging and reverse engineering Java applications in real time, without the limitations typical of JVM agents. Through a combination of DLL, JNI, and JVMTI, JDBG offers insights into class structures, bytecode analysis, and field values, as well as dynamic breakpoint setting and stack inspection during program execution. These features enable precise diagnostics and the detection of vulnerabilities or modifications in the code.
What’s more, the tool includes a “workspace” of objects that allows you to gather and filter class instances (e.g., using the external Exprtk library), helpful for discovering relationships among objects during runtime.
JavaRansomware
JavaRansomware by Panagiotis Drakatos is an experimental pure Java application demonstrating how modern ransomware attacks theoretically operate. The project uses hybrid encryption (AES-256 for file encryption and RSA-4096 to secure the AES key) and automatically scans specified folders to encrypt their contents. Its purpose is to show the techniques and mechanisms used by real attackers, such as selecting files on the system or transporting encryption keys, allowing security researchers and developers to understand the encryption process and prepare for potential threats.
The tool is available exclusively for educational and research purposes. The author emphasizes it must not be used for conducting attacks or breaching security without authorization
P.S.: Today’s images were generated using 4o Image Generation, which appeared this morning. Expect more experimentation with style, because the effect is awesome.
