Java Roundup – March 2 2026
A quick pulse‑check
If you’ve been living under a rock (or, more plausibly, buried in a monorepo), you might have missed a handful of releases that landed this week. Nothing dramatic enough to rewrite the language, but enough to keep the “what’s new” radar humming. Think of it as the weekly “kettle‑boil” of the Java ecosystem: a steady simmer of bug‑fixes, a few new knobs to turn, and a splash of community news that reminds us why we love open source.
Below is my attempt to stitch together the bits that caught my eye while I was still nursing a coffee at the Devnexus registration desk and scrolling through the JDK early‑access feed on my phone. I’ll sprinkle in a few anecdotes, some analogies that (hopefully) make the technical details a bit more digestible, and a few honest “I’m not sure yet” moments – because even after 15 years of covering Java, I still get surprised.
JDK 26 Build 35 & JDK 27 Build 12 – Early‑Access, Still in the Lab
First up, the ever‑present JDK early‑access builds. If you’ve ever tried to bake a soufflé, you know the difference between a recipe that’s been tested a dozen times and one that’s still in the “experimental” section of the cookbook. JDK 26 Build 35 (the current GA‑candidate) and JDK 27 Build 12 (the newest preview) sit squarely in that experimental kitchen.
What’s new?
-
JDK 26 Build 35 – The official tag lives on GitHub [1]. The release notes are a dense list of incremental fixes and a few performance tweaks, most of which target the new
VectorAPIand the foreign‑memory access improvements introduced in the previous builds. Nothing that will make you drop your IDE and start a new project tomorrow, but the polish is noticeable if you benchmark a tight loop that does a lot of vector math. -
JDK 27 Build 12 – This week’s drop (see the GitHub tag [2]) includes a handful of bug‑fixes that were holding back the new
ScopedValuesfeature from being fully usable in a multi‑threaded context. The change‑log comparison [3] shows that a handful of JDK‑specific CVEs were also patched, which is always welcome.
Both builds are still early‑access, so expect some rough edges. If you’re the kind of developer who likes to “live on the edge” (or you have a test environment that can afford a few crashes), give them a spin. Otherwise, stick with the current LTS (JDK 21) and keep an eye on the release notes for any breaking changes that might affect your downstream libraries.
Pro tip: When testing early‑access builds, isolate them in a Docker container or a dedicated SDKMAN! installation. It saves you from accidentally pulling the wrong JDK into a production CI pipeline.
Sources: JDK 26 Build 35 [1], JDK 27 Build 12 [2], release notes [4][5], bug database [6][7].
Apache Solr 10 – GA, With a Fresh Admin UI
Apache Solr finally hit GA with version 10.0.0, and the release feels a bit like the moment you finally upgrade from a clunky old kitchen mixer to a modern stand‑alone unit that actually has a digital display.
Highlights
| Feature | Why it matters |
|---|---|
| New experimental Admin UI | A modern, more secure UI that no longer leans on deprecated code. It’s still labeled “experimental,” but the UI is slicker, and the security improvements are welcome – especially for teams that expose Solr dashboards to internal users. |
Support for SeededKnnVectorQuery and PatienceKnnVectorQuery |
These new Lucene‑based K‑Nearest‑Neighbour queries give you more control over vector search, a hot topic now that LLM‑driven embeddings are everywhere. |
| Scalar & binary quantized dense vectors | By quantizing vectors you can cut memory usage and improve query latency. Think of it as compressing a high‑resolution image without losing the essential details needed for a quick visual search. |
If you’ve been using Solr for a while, you’ll notice the UI change right away. The old “classic” UI was functional but felt like a relic from the early 2000s. The new one is responsive, has built‑in role‑based access controls, and, importantly, it doesn’t rely on the now‑EOL Jetty version that was a security headache.
The real excitement, though, is the vector search enhancements. With LLM embeddings becoming a first‑class citizen in many Java services, having native support for efficient K‑NN queries inside Solr is a big step forward. You can now store dense vectors directly in Solr documents and run similarity searches without pulling data into a separate vector database.
Sources: Solr 10 GA release notes [8], Lucene query classes [9][10].
LangChain4j 1.12.1 – Embeddings Meet Hibernate
LangChain4j, the Java sibling of the popular Python LangChain library, dropped version 1.12.1 (alongside a “twenty‑first” beta). If you’ve ever tried to fit a square peg into a round hole, you’ll appreciate the new HibernateEmbeddingStore that finally lets you persist LLM embeddings in a relational database without a custom schema hack.
What’s inside?
-
HibernateEmbeddingStore– A thin wrapper that maps embedding vectors to a Hibernate‑managed entity. The underlying table stores the vectors as binary blobs (or as the newhibernate‑vectortype if you’re on the latest Hibernate). This makes it trivial to query embeddings using JPQL or Criteria API, which is a relief if you’re already deep into a Spring‑Boot + JPA stack. -
MicrometerChatModelListenerimprovements – The listener now pushes counters and a latency timer into Micrometer. If you’ve ever tried to eyeball the performance of a chat model call in production, you’ll thank this addition. It’s the kind of telemetry that lets you spot a sudden spike in latency before your users start complaining.
The release is mostly bug‑fixes and dependency upgrades, but the two features above feel like the first solid steps toward a “full‑stack” Java LLM workflow. In other words, you can now train, store, retrieve, and monitor embeddings without leaving the Java ecosystem.
Sources: LangChain4j 1.12.1 release notes [11].
Grails 7.0.8 – A Smoother Test Ride
Grails isn’t the flashiest framework in the Java world, but it still powers a surprising number of internal tools and micro‑services. Version 7.0.8 landed with a few quality‑of‑life upgrades that reminded me of the difference between a squeaky bike chain and a freshly lubricated one.
Key additions
-
@DatabaseCleanupannotation – This new test‑support annotation wipes all tables after each test run. If you’ve ever spent an hour debugging flaky integration tests because leftover data from a previous test polluted the next one, you’ll love this. It works at the framework level, so you don’t need to manually clean up tables in each test class. -
Improved Groovy Joint Validation CI workflow – The CI pipeline now reduces JVM memory usage and adds safeguards against flaky tests that could otherwise crash the whole build. The changes are subtle, but they translate into faster CI feedback and fewer “out‑of‑memory” crashes on shared agents.
Overall, Grails 7.0.8 feels like a maintenance release that finally addresses some of the pain points that have lingered for a few releases. If you’re still on Grails 6, the upgrade path is straightforward, and the new testing utilities alone might make the move worthwhile.
Sources: Grails 7.0.8 announcement [12], release notes [13].
JobRunr 8.5.0 – Faster Starts, Fewer Fork‑Join Frustrations
JobRunr is the “fire‑and‑forget” background job library that many Java teams use as a lighter‑weight alternative to heavyweight BPM tools. Version 8.5.0 brings a couple of under‑the‑hood improvements that feel like a well‑timed oil change for a high‑revving engine.
What changed?
-
Startup performance boost – Previously, JobRunr would execute a separate SQL query for each migration script during startup. The new batch‑query approach slashes that overhead, which is noticeable in containerized environments where every second counts.
-
Java AccessControlException fix – A niche bug that surfaced when the library called
ForkJoinPool.commonPool()from an application that still used the deprecatedSecurityManager. The fix makes JobRunr more robust when running under strict security policies (e.g., in certain corporate JDK installations).
If you’re already using JobRunr, you’ll see a modest reduction in startup latency. If you’re on the fence, the reduced startup cost might be the nudge you need to try it out for small‑scale background processing.
Sources: JobRunr 8.5.0 blog post [14], release notes [15].
Multik 0.3.0 – Kotlin’s Answer to NumPy (Getting Closer)
Multik is the Kotlin library that brings multi‑dimensional arrays to the JVM. Version 0.3.0 adds a couple of features that make it feel a little less like a hobby project and a bit more like a serious scientific‑computing tool.
New goodies
-
normAPI – A new function that computes vector norms (L1, L2, etc.) directly onMultiArrayinstances. This is handy when you’re working with embeddings or any high‑dimensional data and need a quick similarity metric. -
Diagonal matrix creator – The
diagonal()method lets you spin up a diagonal matrix without manually constructing a full 2‑D array and then zeroing out the off‑diagonal entries. It’s a tiny convenience, but in a language where boilerplate can be verbose, every shortcut counts.
The release also includes documentation improvements and a few dependency upgrades. If you’re doing data‑science work in Kotlin, Multik 0.3.0 makes the experience a tad smoother, and the new norm function is a nice bridge toward the kind of vector math you see in Python’s NumPy or SciPy.
Sources: Multik 0.3.0 release notes [16].
Gradle 9.4.0 – JDK 26 Ready, Test Engine Tweaks
Gradle’s GA release of 9.4.0 landed with a few headline items that will affect most Java builds, especially those that have already upgraded to the latest JDK preview.
Highlights
-
JDK 26 support – Out‑of‑the‑box compatibility with the upcoming JDK 26 means you can start experimenting with the new
VectorAPIandScopedValueswithout waiting for a later Gradle patch. -
Custom JUnit TestEngine integration – Gradle now supports test engines that implement the JUnit Platform
TestEngineinterface without requiring a concrete test class. This opens the door for frameworks that generate tests on the fly (think property‑based testing or dynamic test generation from DSLs). -
Configuration cache reporting improvements – When you have multiple lambdas in a configuration cache, Gradle now tags each lambda with its type of action. The result is clearer diagnostics when something goes wrong, which saves you from digging through a stack trace that looks like a cryptic puzzle.
If you’ve been wrestling with flaky CI builds or slow test suites, give the new test engine support a try. It’s not a silver bullet, but it does make the Gradle‑JUnit integration feel less “hand‑cuffed.”
Sources: Gradle 9.4.0 GA release [17], release notes [18].
Keycloak 26.5.5 – Security Patches, No New Features
Keycloak’s latest maintenance release (26.5.5) is a reminder that sometimes the most important work is fixing what’s already broken. Four CVEs were patched, all revolving around SAML IdP broker flows.
The CVEs, in plain English
| CVE | What it allowed | Why it mattered |
|---|---|---|
| CVE‑2026‑3047 | Bypass authentication as an Identity Provider broker when a SAML client was disabled. | An attacker could impersonate a trusted IdP, opening the door to unauthorized access. |
| CVE‑2026‑3009 | Authenticate using a disabled IdP after an admin turned it off. | Similar to the above, but leveraged a flaw in the performLogin() method. |
| CVE‑2026‑2603 | Complete an IdP‑initiated broker login via a specific endpoint even when the SAML IdP was disabled. | Shows how a disabled service can still be abused via a different code path. |
| CVE‑2026‑2092 | Inject an encrypted SAML assertion to hijack a brokered flow. | A classic “man‑in‑the‑middle” style attack that could lead to account takeover. |
No new features, just a solid patch set. If your organization relies on Keycloak for SAML federation, upgrade ASAP. The release notes also remind us to keep an eye on the Java Bug Database for any downstream JDK issues that could affect Keycloak’s cryptographic libraries.
Sources: Keycloak 26.5.5 announcement [19], CVE details [20][21][22][23].
Devnexus 2026 – The Java Community in Full Swing
I spent three days at Devnexus in Atlanta this week, and the energy was palpable. The conference has always been a “Java‑by‑the‑people, for the‑people” event, and 2026 was no exception. Here are the sessions that stuck with me.
AI‑first tracks
-
Generative AI in Java – A hands‑on workshop that walked through building a simple text‑to‑image generator using the new
VectorAPIfor embedding storage and LangChain4j for prompt orchestration. The presenter (a former Google researcher) emphasized that you don’t need a massive GPU farm to experiment; a modest cloud instance plus the right Java libraries will do. -
AI in Practice – Production Tips – A panel of engineers from Netflix, Uber, and a few startups discussed how they handle model versioning, monitoring, and rollback. The takeaway? Treat your model like any other library dependency: pin versions, write integration tests, and automate rollbacks.
Core Java & Frameworks
-
Project Loom’s Future – A deep dive into virtual threads, with live demos showing how a simple web service can handle 100 k concurrent requests on a single 8‑core machine. The presenter’s analogy was spot‑on: “Virtual threads are to Java what threads are to a kitchen – you can now have a hundred chefs chopping veggies without the kitchen exploding.”
-
Grails 7 – From Monolith to Microservices – A case study from a large retailer that migrated a legacy Grails monolith into a set of micro‑services while retaining the same codebase. The speaker highlighted the new
@DatabaseCleanupannotation (yes, the one we mentioned earlier) as a key factor in keeping integration tests reliable during the migration.
Security & Tools
-
Keycloak Hardening – A short session that walked through the CVEs patched in 26.5.5 and demonstrated how to audit your IdP configurations. The speaker’s live demo of a misconfigured SAML client was a wake‑up call for anyone still treating SAML as “set‑and‑forget.”
-
Mentoring Hub – The all‑day mentorship space, run by Bruno Souza and Luiz Real, was a goldmine. I sat down with a junior developer who was trying to integrate LangChain4j with a Spring Boot app. We walked through the new
HibernateEmbeddingStoretogether, and by the end of the hour she had a prototype ready for her thesis. It’s moments like these that remind me why I keep attending conferences: the ripple effect of a single conversation can be huge.
Overall, Devnexus reinforced a trend I’ve been seeing for a while: the Java ecosystem is no longer just about “enterprise back‑ends.” It’s a playground for AI, data science, and even edge computing (thanks to projects like Pi4J). The community’s willingness to experiment, share, and iterate is what keeps the language relevant.
Sources: Devnexus 2026 website [24], speaker list [25], mentorship hub [26].