As a hub for the Friends of OpenJDK (Foojay.io) continues to be one of the better places to track what is actually happening in the JVM ecosystem month-to-month. And this month’s main feature connects rather neatly to where we left off.

Last month, David Vlijmincx walked us through the sharp edges of the FFM API - VarHandle access modes, memory fences, the places where Panama makes you think like a hardware engineer. This month we get to see what happens when somebody builds an entire ecosystem on top of that machinery. Andrea Peruffo - the maintainer behind Chicory and one of the people who has done the most to make WebAssembly a first-class citizen on the JVM - published a piece arguing that we’re watching a new generation of Java libraries being born.

I’ve been following the Chicory story for a while now, and this article lands at a genuinely interesting inflection point. Let’s dig in.

A New Generation of Java Libraries Is Born: Wasm Becomes the Implementation Detail

If you’re running JRuby in production, you’re running WebAssembly. If TrinoDB is evaluating your Python UDFs, that’s WebAssembly too. If Microcks is running JavaScript dispatchers to route your mock API responses, WebAssembly is doing the work.

You didn’t install a native binary. You didn’t configure JNI. You didn’t cross-compile anything for your target platform. It just works, because the Wasm module is hiding inside a regular JAR on your classpath.

This is the same pattern that already powers the web. Every day, millions of people use Google Sheets, Figma, or Photoshop without knowing that WebAssembly is what makes those applications possible. Wasm is already invisible infrastructure in the browser. Now the same thing is happening on the JVM.

The problem every Java developer knows

Some of the best libraries in the world are written in C, C++, Rust, or Go. SQLite. QuickJS. Protocol Buffers. OPA. They are battle-tested, widely deployed, and actively maintained. At some point, every Java project wants to use one of them.

The options have never been great. You can rewrite the library in Java, but that’s expensive, error-prone, and perpetually behind the upstream. Or you can reach for JNI and ship platform-specific native binaries. That path comes with its own pain: your application becomes OS and architecture-specific. Execution leaves the safety and observability of the JVM. Distribution turns into a matrix of .so, .dylib, and .dll files. Debugging across the JNI boundary is nobody’s idea of fun. And if you’re in a restrictive environment, such as a locked-down container or a platform that blocks native library loading, JNI may not be an option at all.

For decades, this trade-off felt permanent. You could have the capability, or you could have the JVM’s guarantees. Not both.

What if the library just ran inside the JVM?

WebAssembly changes this equation. Take a proven C or Rust library, compile it to Wasm, and run it within JVM boundaries. You keep everything the JVM gives you: guaranteed memory safety, fault isolation, platform independence, advanced JIT, observability, and the “write once, run anywhere” promise. The Wasm module becomes just another artifact inside your JAR, an implementation detail that your users never need to think about.

This isn’t a theoretical possibility. It’s happening right now, in production, across a growing ecosystem of Java libraries.

The ecosystem: it’s already here

SQLite4j is a pure-Java JDBC driver for SQLite. The real SQLite, compiled to WebAssembly and embedded in a JAR. Before: you shipped platform-specific native binaries for every OS and architecture your users might run on, and hoped your CI matrix covered them all. After: one JAR, everywhere. Same SQLite, zero native dependencies. Add a Maven dependency and you have an embedded relational database.

QuickJs4j puts a full JavaScript runtime inside your Java application. QuickJS, a small, fast, standards-compliant JS engine, is compiled to Wasm and wrapped in a clean Java API. It’s already powering real production systems. Microcks, a CNCF project, uses it for JavaScript dispatchers that control how mock responses are selected based on request headers, payloads, and parameters. It works across all Microcks distributions, including native-compiled images. Before: reach for Nashorn or Rhino (both deprecated), or GraalJS (heavy dependency). After: a lightweight, sandboxed JavaScript engine in a single dependency.

pglite4j embeds PGlite, a lightweight PostgreSQL build, inside the JVM via WebAssembly. In-process, no external server, no native binaries. Useful for testing, local development, or anywhere you need Postgres compatibility without running a separate process.

Protobuf4J compiles protocol buffers without the massive native protoc toolchain. Compile-time dependencies drop from 403MB to roughly 90MB. Same output. Fraction of the footprint.

JRuby uses Prism, the Ruby parser, compiled to Wasm and consumed from Java without JNI. The JRuby team didn’t have to rewrite a parser or maintain platform-specific binaries. They added a dependency.

TrinoDB runs user-defined Python functions inside the query engine, sandboxed via WebAssembly. Users write Python UDFs; Trino executes them safely within JVM boundaries.

And the list keeps growing: Debezium single message transforms, OpenFeature flag evaluation, OPA policy engine running in-process (no network hop to an external sidecar), and more.

The pattern is always the same. Take a proven library. Compile it to Wasm. Wrap it in a JAR. Ship it on Maven Central. Your users add a dependency and get the capability. No JNI, no platform matrix, no native binary management. Wasm becomes the implementation detail.

Endive: a new chapter for WebAssembly on the JVM

This entire ecosystem was built on Chicory, a pure-Java WebAssembly runtime started in September 2023. Within two years it went from experiment to infrastructure, powering production systems across multiple organizations and proving that WebAssembly fits naturally into Java applications.

Now the project is entering its next chapter. Endive is a fork of Chicory and a Bytecode Alliance Hosted project, a vendor-neutral home where the project can grow openly. The community, the vision, and the code carry forward under the same Apache-2.0 license. What changes is that the project now belongs to its ecosystem.

Why the Bytecode Alliance? The BA is the foundation behind Wasmtime, WASI, and the Component Model: the core runtime, system interface, and component standard that define WebAssembly outside the browser. If Wasm is to become a durable cross-language component format, the JVM, one of the world’s major managed runtime ecosystems, needs to be part of that story. Endive gives the BA community a place to collaborate on JVM integration directly.

The first major milestone is integrating the experimental Redline compiler into the mainline. Redline uses Cranelift, the same compiler backend behind Wasmtime, to compile Wasm to native machine code. On Java 25+, it achieves this with zero additional dependencies, thanks to Panama’s Foreign Function & Memory API becoming a standard part of the platform. You get native-speed execution and the pure-Java packaging story.

Further out, the roadmap includes WasmGC, enabling the Java garbage collector to manage Wasm object references, and Component Model support for consuming cross-language components through typed interfaces.

For the full story on the fork, the governance model, and the migration path for existing Chicory users, see the Bytecode Alliance announcement.

Compose, don’t rewrite

The future isn’t about rewriting native libraries in Java. It isn’t about wrestling with JNI or maintaining platform-specific builds. It’s about composing your application from components written in any language (Rust, C, Go, Python, JavaScript) through WebAssembly.

One runtime. Any language. No rewrites.

Java has always been about writing code once and running it anywhere. WebAssembly extends that promise to any codebase in any language. With Endive, the JVM becomes a place where established libraries, regardless of what language they were written in, can run safely, portably, and at native speed.

Wasm becomes the invisible glue. The implementation detail that makes it all work, without you even noticing.

Get involved

The Endive repository is already available. The first release will prioritize strong continuity with Chicory, preserving compatibility and documenting migration steps clearly.

If you care about Java, WebAssembly, secure plugin systems, cross-language components, or the future of portable software, come build with us.

Also on Foojay This Month

Foojay Podcast #95: Is Your Java App Actually Secure, Or Does It Just Look That Way?

Frank Delporte (Java Champion at Azul) sat down with Steve Poole and David Welch , both from HeroDevs, for an episode of the Foojay Podcast that I’d file under “uncomfortable but necessary.”

Steve brings his concept of zombie dependencies - end-of-life libraries that look safely dormant while quietly accumulating vulnerabilities nobody will ever file a CVE against. David, co-chair of the CVE Automation Working Group, explains how the identification and disclosure process actually works - and why AI tooling is dramatically accelerating the pace at which new vulnerabilities get found, on both sides of the wall. That last clause is the one to sit with: the same automation that helps defenders triage is helping attackers prospect.

BTW: This one pairs almost suspiciously well with Steve’s CRA article below - consider them a double feature.

Context Is a Budget - Eight Levers and Three Workflow Patterns

Soham Dasgupta opens with a hook designed to get forwarded to engineering managers: a team of fifty developers can quietly burn $30,000 a month on AI coding assistants without anyone having a story for where it went. The rest of the article is the most practical treatment of AI-assistant cost discipline I’ve seen on Foojay - and I say that as someone professionally obligated to read all of them.

The mental model is in the title: stop treating the context window as a free buffet and start treating it as a budget you spend on every turn. The detail most people miss - and the article backs with research from Anthropic and Chroma - is context rot: model recall and reasoning degrade as the window fills, well inside the advertised limit. More context isn’t just expensive; past a point it’s actively harmful. The other quietly brutal number: every connected MCP server ships its full tool schemas with every request, so five servers can cost you 5,000-10,000 tokens per turn before you’ve typed a word - whether the model uses the tools or not.

The eight levers (context engineering, prompt caching, MCP hygiene, instruction files, model routing, output discipline, repo hygiene, observability) are each delivered with a “do this Monday” action, and the three workflow patterns escalate from the gloriously named Ralph Wiggum loop (cheap model + TODO.md + relentless iteration, state on disk instead of in conversation tokens) to a planner → implementer → reviewer split that routes expensive models only to the work that needs them.

None of it is rocket science, which is rather the point - as Soham puts it, most teams don’t have a token problem, they have a discipline problem. The piece already made the rounds via Baeldung’s weekly review, deservedly.

Tiberius: A Security Testing Framework for LLM Applications in Java

Iryna Dohndorf - whom regular readers may remember from last month’s anniversary podcast - opens her introduction of Tiberius with the question every team shipping LLM features eventually faces: how do you write a regression test for a system that is non-deterministic by design?

Tiberius is an open-source (Apache 2.0) Java library that answers it with a scan-fixture-validate workflow. A scan fires 200+ attack probes - jailbreaks, prompt injection, encoding evasion, data extraction, multi-turn escalation, all mapped to the OWASP LLM Top 10 - against your deployed model and serializes whatever got through to a JSON fixture. That fixture becomes version-controlled ground truth: your guardrails then get tested against attacks that actually bypassed your model, not the handful of examples a developer imagined. Both block rate and false-positive rate are first-class metrics.

Spring Boot Migration and the CRA: When Good Enough Isn’t

Steve Poole again, this time in writing, and with a date you should put in your calendar twice. The article is a follow-up to his April piece on zombie dependencies, and the framing has shifted from technical risk to legal risk: Spring Boot 3.5 reaches end of open-source support on June 30, and the EU Cyber Resilience Act starts coming into force on September 11.

The mechanics are worth knowing precisely. CRA Article 14(1): if a product you ship contains a vulnerability that’s actively being exploited and you become aware of it, you owe ENISA and your national CSIRT an early warning within 24 hours, a full notification within 72, and a final report within 14 days of a corrective measure being available. The trigger is active exploitation - not CVE assignment, not a severity score. And then you must address it “without undue delay,” a phrase that EU regulators interpret relative to what was reasonably available to you.

Here’s Steve’s sharpest point: after June 30, the upstream patch for 3.5 no longer exists - but commercial support does. Which means the regulator’s question stops being “why didn’t you take the upstream fix?” and becomes “why didn’t you use one of the available options to get a patch anyway?” Once commercial backports exist, “there was nothing we could do” stops being true. Steve works for HeroDevs and says so openly, which I appreciate - the argument holds regardless of who benefits. With the Spring community’s own guidance recommending migrations start nine to twelve months before EOL (a window that opened in July 2025), and medium codebases running 12-14 weeks, “we’ll migrate in six months” is about to become a much harder sentence to say to a regulator. A different flavor than the rest of this edition - regulation plus enterprise - but if you’re anywhere near compliance conversations, this is the one to forward.

Jakarta EE is Ready for AI – But Don’t Just Take My Word for It!

Dominika Tasarz (Senior Developer Advocate at Azul, and Frank’s new Foojay colleague as of episode #94) put together a roundup of five talks from Open Community Experience 2026 in Brussels that, taken together, make a coherent argument: enterprise Java doesn’t need framework gymnastics to do AI.

The sequencing is smart. Ivar Grimstad (Eclipse Foundation) provides the orientation talk - from J2EE’s famous pain through Jakarta EE 10/11 to the EE 12 roadmap and early AI standardization moves. Then Luqman Saeed (Azul) delivers a two-talk arc that I’d call the heart of the post: first the “intelligent monolith” - a full RAG pipeline with CDI, LangChain4j, pgvector, and Ollama, escalating all the way to in-process inference with Jlama running the model inside the JVM - and then the microservices variant, where Jakarta Data repositories store embeddings as plain JPA byte arrays with cosine similarity in plain Java, and Jakarta Concurrency 3.1’s virtual threads handle the I/O-bound inference work. What Dominika rightly highlights is Luqman’s honesty about limits: in-memory vector search works until it doesn’t, and he tells you what signals mean it’s time for a real vector database.

Kenji Kazumura (Fujitsu) then asks the production question - supervisor agents coordinating sub-agents over MCP, with JWT propagation, OpenTelemetry tracing, and compensation patterns where ACID can’t reach - and introduces the Jakarta Agentic AI project aiming to standardize agent lifecycle across the ecosystem. Rustam Mehmandarov closes with the necessary cold shower: all of these agents talk over APIs, and your AI architecture is worth very little if those APIs are fragile and badly versioned.

Five talks, all with recordings embedded, and a useful counterweight to the assumption that “Java + AI” automatically means Spring.

And that’s all, folks.

PS: JDD in Krakow is looking for speakers! We’re looking for in Call for Papers submissions. 🧠

👉 We’re accepting them until June 21

Today is the day: June 4th, JDK 27 enters the Rampdown phase and forks off the main line. Rampdown means the feature list gets frozen and no further new features are to be expected - so the set you see below is the set we’re getting in September.

Just like JDK 26, this is a lean release - and, as tradition now dictates, a non-LTS one (the second non-LTS since the JDK 25 LTS last September; the next LTS won’t arrive until JDK 29 in 2027).

Yeah, I know there is not a thing like LTS in Java.

So if you were waiting for a blockbuster on the scale of HTTP/3, this isn’t it. But don’t let the size fool you - there’s one genuinely important security headline here, and two quietly consequential default flips that will touch almost every Java process on the planet.

For the calendar-minded, the full schedule, approved by Mark Reinhold:

• Rampdown Phase One (fork from main line): June 4, 2026

• Rampdown Phase Two: July 16, 2026

• Initial Release Candidate: August 6, 2026

• Final Release Candidate: August 20, 2026

• General Availability: September 14, 2026

Now, let’s go through the complete list of changes in the new edition.

Cryptography Updates

JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

If there’s a single reason to pay attention to JDK 27, this is it. JEP 527 brings post-quantum cryptography into the TLS handshake itself - and, crucially, it does so by default, with zero code changes on your side.

The problem it solves: quantum computers capable of breaking RSA and Elliptic-Curve Diffie-Hellman don’t exist yet. But that’s cold comfort, because of the wonderfully ominous “harvest now, decrypt later” threat model: an adversary records your encrypted traffic today, sits on it, and decrypts it the day a sufficiently large quantum computer shows up. For anything that needs to stay secret for years (medical records, state secrets, that embarrassing Slack export), the clock is already ticking.

The solution: the IETF TLS Working Group settled on hybrid key exchange - combine a battle-tested classical algorithm with a quantum-resistant one, and you’re safe as long as either survives. This hedges against quantum attacks while acknowledging that the new lattice-based algorithms haven’t yet had decades of cryptanalysis thrown at them. JDK 27 implements three such schemes, each pairing ML-KEM with Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE):

• X25519MLKEM768 - X25519 + ML-KEM-768

• SecP256r1MLKEM768 - secp256r1 + ML-KEM-768

• SecP384r1MLKEM1024 - secp384r1 + ML-KEM-1024

This is the natural next step in a multi-release journey: the KEM API arrived in Java 21 (JEP 452), the ML-KEM algorithm itself in Java 24 (JEP 496), and now JDK 27 wires them into TLS 1.3.

The best part: TLS clients advertise their supported “named groups” in preference order during the handshake, and X25519MLKEM768 goes straight to the front of that list. So any code using javax.net.ssl gets quantum-resistant handshakes automatically - provided it doesn’t already pin specific named groups. If you do want to take control, you can override the default list via the jdk.tls.namedGroups system property, or per-connection:

SSLSocket tlsSock = (SSLSocket) SSLContext.getDefault()
.getSocketFactory().createSocket();

SSLParameters params = tlsSock.getSSLParameters();

// Two hybrid KEM schemes plus two traditional ones

params.setNamedGroups(new String[] {
   "SecP256r1MLKEM768", "X25519MLKEM768", "secp256r1", "x25519"
});

tlsSock.setSSLParameters(params);

One caveat worth flagging (and the JEP authors flag it too): the underlying IETF specifications for hybrid key exchange are still in draft status. The feature ships only once those drafts graduate to RFCs - so if the standard wobbles, this could in theory slip. But everything points to it landing.

JEP 538: PEM Encodings of Cryptographic Objects

Sticking with the security library, JEP 538 finally finalizes the PEM encoding/decoding API after a patient two-preview run - JEP 470 in JDK 25 and JEP 524 in JDK 26 (longtime readers will recall me covering both).

For the uninitiated: cryptographic objects live in binary DER format - great for machines, unreadable for humans. PEM (Privacy-Enhanced Mail) wraps that DER in Base64 with those familiar -----BEGIN ...----- headers, which is what actually ends up in your Git repos, server configs, and copy-pasted email threads. Until this API, Java had no first-class way to convert between the two, so everyone reached for hand-rolled parsers or third-party libraries.

String pem = PEMEncoder.of().encodeToString(privateKey);  // object → PEM

PrivateKey key = PEMDecoder.of().decode(pem, PrivateKey.class);   // PEM → object

The finalization brought two notable tweaks. The PEMRecord class was reclassified from a record to a regular class, which lets it offer convenience constructors that accept Base64-encoded content directly as byte arrays. And the marker interface formerly known as DEREncodable was renamed to BinaryEncodable - a more honest description of the binary data actually sitting inside the PEM text. Nothing earth-shattering, but it’s nice to finally retire the “(Preview)” suffix.

Squeezing the Memory

JEP 534: Compact Object Headers by Default

JEP 534 promotes compact object headers to the default layout in HotSpot. The feature itself is the one we met in JDK 25 as a production option (JEP 519), having started life as an experimental flag back in JDK 24.

Quick refresher on why anyone cares: the standard 64-bit HotSpot object header is two machine words - a mark word and a class pointer. With millions of live objects, that second word adds up to tens of megabytes of pure overhead, doubles GC traffic, and trashes your CPU cache. Compact headers squeeze the mark word, a compressed class pointer, and a few meta bits into a single 64-bit value, while keeping all the functionality you rely on (hashCode, synchronization, locking).

After large-scale production hardening (Amazon famously ran it across hundreds of services), the layout has proven itself enough to become the default. From JDK 27 onward you get the memory savings for free - and if for some reason you need the old behaviour, -XX:-UseCompactObjectHeaders is still there to turn it off. A rare case of a release where you do less and get more.

JEP 523: Make G1 the Default Garbage Collector in All Environments

JEP 523 is the kind of change that sounds boring until you realize how many edge cases it quietly eliminates. As nipafx would gleefully remind us, the JCP doesn’t technically recognize the concept of a “default garbage collector” - but in practice HotSpot has to pick something when you don’t, and that pick has been inconsistent for a decade.

Here’s the history: G1 became the default for server-class machines in JDK 9 (JEP 248) - that is, anything with at least 2 hardware threads and roughly 2 GB of RAM. Below that threshold (single CPU, less than ~1792 MB), HotSpot silently fell back to Serial GC, because back in 2017 Serial genuinely had the edge on throughput and footprint in cramped environments.

Note the past tense. Over the last several releases G1 has been relentlessly optimized: its native memory footprint came down, and the second card table introduced by JEP 522 in JDK 26 (the one I spent way too many paragraphs explaining in vol. 157) brought its throughput within spitting distance of Serial’s. G1’s maximum latencies, meanwhile, have always beaten Serial’s, since it reclaims the old generation incrementally rather than via stop-the-world full collections.

So the conclusion writes itself: G1 is now competitive at all heap sizes, and there’s no longer a good reason to surprise users with a different collector just because they’re running on a small box. From JDK 27, if you don’t specify a GC, you get G1 - period, regardless of cores or memory. A welcome side effect: the AlwaysActAsServerClassMachine and NeverActAsServerClassMachine flags lose most of their purpose and are now deprecated for removal. And of course, an explicit -XX:+UseSerialGC still does exactly what it says - this only changes the implicit choice.

Observability & Tooling

JEP 528: Post-Mortem Crash Analysis with jcmd

JEP 528 wants to extend the trusty jcmd tool so it can diagnose a JVM after it has crashed - poking at core dumps to extract the kind of post-mortem detail you’d otherwise need the aging jhsdb utility or the Serviceability Agent for. The intent is consolidation: stop spreading “what happened when it died” across three different tools and bring it home to jcmd, where the living-JVM diagnostics already live.

Why does moving this into jcmd matter? Because jhsdb and the Serviceability Agent are the crusty, half-forgotten corner of the toolbox - powerful, but fiddly, poorly documented, and the kind of thing you re-learn from scratch every time production falls over at 3 a.m. jcmd, by contrast, is the modern, unified entry point most of us already reach for. Folding crash analysis into it means one tool, one mental model, for both the JVM that’s still breathing and the one you’re performing an autopsy on. This one had me a little nervous right up to the freeze - but it made the cut, and I’m genuinely glad it did.

JEP 536: JFR In-Process Data Redaction

JEP 536 plugs a leak that’s bitten more teams than will admit it. JDK Flight Recorder captures, among other things, your command-line arguments, the initial values of environment variables, and system properties - which is fantastic for debugging and terrible when that .jfr file (often containing a database password or API token passed via -D...) gets shipped off to a vendor, a support ticket, or a shared bucket.

This JEP lets JFR redact sensitive information in-process, before the recording is even finalized, so the secrets never make it to disk in the first place. It’s the sort of unglamorous, defense-in-depth feature that nobody asks for in a survey but everybody benefits from. Currently Proposed to Target, but it looks comfortable.

Nihil Novi Sub Sole - (Yet More) Preview Features

And now the part of the release notes where, as ever, the preview features file past for another lap. If you’ve been reading this newsletter for any length of time, you can probably recite these from memory - but let’s note what (little) changed.

JEP 531: Lazy Constants (Third Preview)

The feature with more names than a witness in protection: Computed Constants → StableValue (JEP 502, JDK 25) → LazyConstant (JEP 526, JDK 26) → and now JEP 531 for round three.

The core idea has been stable throughout: compute a value exactly once, lazily, in a thread-safe way, and let the JVM treat it as a true constant afterwards (constant-folding and all), so you get lazy initialization without paying the usual synchronization tax.

The third preview makes two changes: it removes the low-level isInitialized() and orElse() methods (they invited usage patterns at odds with the API’s design goals), and it adds a Set.ofLazy(...) factory. With that addition, all three fundamental collection types - List, Set, and Map - now have lazy variants where each element sits in its own LazyConstant and initializes only on first access.

As I showed back in vol. 171, this lets you write things like:

enum Option { VERBOSE, DRY_RUN, STRICT }

// Each element initialized lazily, only on first touch

static final Set<Option> OPTIONS =

    Set.ofLazy(EnumSet.allOf(Option.class), Application::isEnabled);

Thread-safe by construction, constant-foldable after the fact. The feature matures a little with each iteration and is clearly circling the runway toward finalization - my bet is JDK 28.

JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview)

JEP 532 brings back - for the fifth time (yes, fifth) - the extension of pattern matching to primitive types across instanceof and switch. This round ships with no changes from the fourth preview (JEP 530, JDK 26), so... you know the drill by now 😉

switch (x.getYearlyFlights()) {
    case 0                  -> "No flights";
    case int i when i >= 100 -> "Gold status!";
    case int i              -> "Regular: " + i + " flights";
}

The authors are simply collecting more real-world feedback before pulling the trigger. One day this will be stable, and we’ll all pretend we weren’t slightly impatient about it.

JEP 533: Structured Concurrency (Seventh Preview)

JEP 533 continues the marathon - the seventh preview of Structured Concurrency, following JEP 525 (sixth preview) in JDK 26. The API treats a group of concurrent subtasks as a single unit of work, with unified cancellation and error propagation, and you still drive it through the StructuredTaskScope.open() factory established in the big sixth-preview revamp:

try (var scope = StructuredTaskScope.open()) {
    Subtask<String>  user  = scope.fork(() -> findUser());
    Subtask<Integer> order = scope.fork(() -> fetchOrder());
    scope.join();
    return new Response(user.get(), order.get());
}

At seven previews, Structured Concurrency is officially testing my ability to find new ways to say “still cooking.” But it’s good cooking, and the shape now feels right.

JEP 537: Vector API (Twelfth Incubator)

And to close, our perennial guest: JEP 537 delivers the twelfth incubation of the Vector API, with no substantial implementation changes since JDK 25. The pitch is unchanged - express vector computations in plain Java that the JIT reliably compiles down to optimal SIMD instructions (AVX, NEON, SVE) on the host CPU.

As I’ve now written so many times it should be a macro: the Vector API stays in incubation until Project Valhalla‘s value classes become available as preview features, at which point it’ll be adapted to use them and promoted to preview. Back in the vol. 157 (JDK 26) edition I admitted I’d honestly expected more Valhalla by now. Reader, I am still waiting. The Vector API and I are growing old together.

So there it is - JDK 27, the second lean non-LTS release in a row. No single feature reorders the universe the way HTTP/3 did in 26, but the shape of the release tells a story: security is hardening (post-quantum TLS by default is a genuinely big deal that most people will never have to think about, which is exactly the point), the defaults are getting saner (G1 everywhere, compact headers on), and the long-running language and concurrency previews keep inching toward the finish line while we collectively hold our breath for Valhalla.

And with that, the list is frozen - no loose threads to report back on this time. See you in the next edition - Friends of OpenJDK (Foojay.io) One 😊. We needed to switch them this time

KotlinConf ate the calendar this month, so Kotlin gets first fiddle in a dedicated Section 0 - and then the usual: Valhalla and Leyden keep grinding, the race to make the JVM the host of AI continues, and a JVM written in Go is here to make sure we don’t get too full of ourselves.

You already know the ROTS rules: this is where everything that didn’t earn its own edition lands before it rots (heh) on my backlog. But May was different. KotlinConf ‘26 happened in Munich and pulled half of the month’s news into its gravity well - the 2.4 line, context parameters, the security policy, the VS Code extension, and the by-now-inevitable “what is Kotlin doing about AI” conversation.

So this time I’m doing something I’ve never done: Section 0, devoted exclusively to KotlinConf and the broader Kotlin world. Everything else slots in behind it, grouped by theme rather than by the order it happened to hit my feed. Let’s go.

0. KotlinConf 2026 - and all things Kotlin

KotlinConf 2026 took place May 20–22 in Munich and marked 15 years of Kotlin - and the way the whole event was framed says a lot. This was a “Kotlin is now load-bearing enterprise infrastructure, please treat it accordingly” kind of conference (pretty please). The keynote highlights read less like a language pitch and more like a maturity declaration - and they’re worth splitting into a few buckets. I’ll go through them in order of how much they’ll actually change your week.

Context parameters are the headliner - and the community is already arguing about them

The flagship language feature in the 2.4 line is context parameters - the long-awaited successor to experimental context receivers and the thing JetBrains has been quietly de-mining since the PSI work in 2.3.20 (which we covered in the March ROTS). In 2.4.0-RC they’re still hidden behind the -Xcontext-parameters flag, but the conference messaging positions the 2.4 line as the one in which they stabilize. There’s also a nice ergonomic touch in the anonymous-context syntax context(_: Type), which lets you inject a dependency without naming the parameter when you only need it to satisfy the compiler.

What’s really interesting, though, is what the r/Kotlin discussion pulled out: people are reading context parameters as the foundation for capability-based architecture, where the compiler treats a type as a statically-tracked capability - you can’t call a function that requires a database handle context unless you can prove you have one, in the style of Scala 3’s capture checking. Compiler-enforced side effects: lovely in theory. But a loud part of the senior crowd pushed back on the “Can-Do” naming convention that usually rides along with it (CanAccessCache, CanWriteAudit) - arguing that this is just dependency injection dressed up as a verb, and that a plain noun interface CacheReader says the same thing with less ceremony. I land somewhere in the middle - the capability framing is real and useful at module boundaries, but if your whole codebase turns into a thesaurus of CanDoX interfaces, you’ve reinvented constructor injection with extra steps. We’ll see which way the idiom goes.

Kotlin 2.4.0-RC: the boring-but-load-bearing stuff.

Beyond context parameters, 2.4.0-RC is the release where the transition to K2 finally burns the bridges: K2 is mandatory, and the old JVM backend is gone entirely. The toolchain now targets JVM bytecode up to version 26, Kotlin/Native GC pause times dropped by ~15% thanks to concurrent marking, and stdlib got primitive overloads for StringBuilder.insert to kill some boxing overhead. One thing to flag in red: the 2.4 stdlib contracts are incompatible with the 2.3 compiler (KT-85948) - that’s a hard break, so don’t mix it in a multi-module build and don’t expect it to go smoothly. PowerAssert’s ABI also stabilized, and the Compose compiler now skips group generation for inline lambdas that don’t contain @Composable calls. Details in What’s new in Kotlin 2.4.0-RC.

Koog 1.0: a stable foundation for agents in Kotlin.

The other big keynote announcement was Vadim Briliantov - Koog’s tech lead and author - shipping the stable Koog 1.0, JetBrains’ open-source framework for building AI agents in Kotlin and Java, running on backend, mobile, KMP, and even in the browser. It’s JetBrains’ centerpiece in the “who builds the production-grade agentic platform” race — and the concrete materialization of the eval-driven-development thesis as an honest answer to LLM non-determinism.

The 1.0 isn’t just a number. Modules now split into stable and beta streams so production code can pin to APIs that won’t break without a deprecation cycle; every previously @Deprecated API is gone (event handlers, pipeline, agent/strategy/DSL, tools, persistence, MCP, Spring autoconfig, RAG - a proper sweep), and the graph DSL node names are finalized. On the technical side: a redesigned Java interop layer, HTTP transport decoupled from Ktor, OpenTelemetry for Kotlin Multiplatform (Langfuse, Weave, and DataDog now run on every Koog target via a Ktor-based OTLP/JSON exporter, not just JVM), and Anthropic prompt caching out of the box.

Add integrations with Spring AI and Ktor, persistence and recovery for long-running agents, and intelligent history compression. Maven Central: ai.koog:koog-agents:1.0.0. If you’re building agents on the JVM and don’t want to drag in a Python stack, this is now the most serious “idiomatic Kotlin all the way down” candidate.

Kotlin/Wasm goes Stable.

From the same RC, but worth its own line: Kotlin/Wasm reached Stable status. After years of “promising but experimental,” Wasm is now a full-fledged target you can lean on. Combined with the broader Wasm-on-JVM momentum (more in Section 1), the “browser as a deployment target” story for Kotlin stops being aspirational.

Maturity in security: JetBrains becomes a CVE Numbering Authority

This is the announcement nobody live-tweeted but the one your compliance team will care about most. JetBrains rolled out a formal security support policy for kotlin-stdlib and kotlin-reflect, and crucially - registered as a CVE Numbering Authority (CNA). That means JetBrains now issues its own CVE identifiers and manages vulnerability disclosure with the same rigor you’d expect from Oracle or Red Hat. The policy guarantees patches for the three most recent minor versions (currently 2.1.x, 2.0.x, 1.9.x), commits to strict binary and source compatibility for those patches, and allows out-of-band hotfixes for critical issues. For anyone deploying Kotlin in finance, healthcare, or anything that ships with an auditor attached, this is the “Kotlin has grown up” paperwork you’ve been waiting for.

KMP: Swift interop without the Objective-C tax, and a real docs portal

The big Kotlin Multiplatform story is direct Swift export - bypassing the Objective-C header bridge, which according to JetBrains yields smaller binaries and lower call-site overhead on iOS. If you’ve ever stared at a mangled Obj-C interop signature wondering where your nice Kotlin API went - this is the fix. Alongside that, JetBrains consolidated the scattered KMP guides into a single learning portal aligned with the Kotlin 2.0.0+ era, covering modern expect/actual patterns, source-set configuration in the Gradle Kotlin DSL, the current Native memory model, Ktor, and SQLDelight. Less “version soup,” more single source of truth. Overdue and welcome.

Backend tooling grows up: Exposed 1.0, kotlinx-rpc, and Spring leaning in

On the server side, the conference finally shipped Exposed 1.0 - API stability for JetBrains’ SQL framework after what feels like a decade of “well, it’s basically stable already.” It comes with: experimental kotlinx-rpc (a pure-Kotlin alternative to gRPC) and native Vector types tuned for similarity search for AI workloads. The Spring alignment also continues - Josh Long was on the ground reinforcing “Kotlin-first” in the evolution of Spring Boot’s API, which remains one of the more significant partnerships for day-to-day JVM productivity. A related release this month is Ktor 3.5.0, keeping the networking layer current.

Kotlin meets AI - and JetBrains wants your data on it

JetBrains pulled two parallel threads here. The first is research: a strategic initiative to close the AI gap between Java and Kotlin, targeting four workflows - completion, chat, autonomous agents, and code review. The honest premise underneath is that LLMs trained on a mountain of Java tend to produce Kotlin with a Java accent - losing DSLs, sealed classes, conciseness - and JetBrains wants to fix this through context injection and Kotlin-specific tuning rather than hoping foundation models figure it out on their own.

The accompanying Kotlin-AI-a2 survey gets at the points of greatest friction: KMP structures, complex coroutine orchestration, and type-safe DSL construction, with an explicit emphasis on improving the K2 compiler’s metadata export so an in-IDE assistant gets real semantic context. If you have an opinion on where AI mangles your Kotlin (you do), this is the survey to fill out.

The second thread is plumbing: kotlin-agent-skills, a framework that exposes the compiler’s own understanding to agents over the Model Context Protocol - search_symbols for semantic indexing, find_usages for the code graph, plus Gradle hooks to actually run compile and run_tests. The pitch is right: stop letting the model guess, and let it correct itself based on real compiler feedback. This is the same “agents grounded in deterministic tooling” thesis JetBrains has been hammering on all year, now aimed squarely at Kotlin. (And yes - this is the repo where the AGP 9.0 migration skill from last month lives, so it’s being actively populated.)

VS Code extension - in alpha, with caveats

JetBrains officially shipped a first-party “Kotlin by JetBrains” VS Code extension in alpha, built on the kotlin-lsp backend. The strategic read is clear: be where the developers are - in lightweight, polyglot editors where IntelliJ isn’t always the default. The realistic read, per the community thread, is more tempered - Neovim users on the same LSP report lag and finicky completion, and KMP support is immature enough to be a dealbreaker for production work. The recurring architectural note also resurfaces: that the old Gradle jvm plugin is becoming a burden and new projects should default to multiplatform. JetBrains frames this explicitly as a “thin” experience for quick edits, not a play for parity - IntelliJ remains the only full-feature option. Good first step; manage expectations.

And for dessert: Gamebit

To close Section 0 with something that isn’t a roadmap slide - JetBrains spotlighted Gamebit by Dmytro Kurets , a board-game AI project that deliberately doesn’t reach for an LLM.

It’s classic algorithmic AI - Monte Carlo Tree Search, Minimax with alpha-beta pruning - implemented in Kotlin with a bitboard representation that packs entire game states into 64-bit primitives to keep GC pressure near zero during deep tree traversals, plus compile-time-enforced legal-move generation, all targeting KMP. In a year where every “AI” headline assumes a transformer, this is a genuinely refreshing reminder that in constrained, heavily logical domains, well-tuned deterministic search eats neural networks for breakfast. Star it for the bit-twiddling alone.

That’s it for Kotlin. Now - the rest of the story.

1. May: The Rest of the Story

Last month I got a little misty over Project Metropolis going to Call For Votes. May delivered the sequel. OpenJDK is moving to deprecate and remove JVMCI - the Java-Level JVM Compiler Interface from JEP 243 that let Graal slot into HotSpot as a C2 replacement via -XX:+EnableJVMCI. Same logic as Metropolis: maintaining a stable interface for an external compiler while HotSpot’s internals churn became unsustainable once the strategic future of Graal as a standalone, vendor-distributed product was settled. Native Image is untouched, but Truffle languages and projects like TornadoVM now have a hard dependency on specific GraalVM builds. If you read the Metropolis section in April and thought “well, that’s the end of Graal in mainline” - this is the formal full stop. A genuinely bold experiment, quietly retired.

Two JDK Reviewer nominations worth noting, both signaling where OpenJDK is allocating its review bandwidth. Casper Norrbin from Oracle’s HotSpot runtime team (45 contributions - a custom red-black tree, string-table optimizations, removal of StatSampler/PerfData) is positioned as a key reviewer for Valhalla‘s integration into mainline, which makes sense given how deep those changes reach into value-type memory layout. Separately, Artur Barashev from Oracle’s Java Security Libraries team (40+ contributions to sun.security.ssl, notably the TLS Certificate Compression work per RFC 8879) was nominated for the security stack - sponsored by veteran Weijun Wang. Both go through the standard Three-Vote Consensus.

I admit a small bias in amplifying that some “Artur” is being promoted. Solidarity.

Two smaller governance items close the topic. A proposal on core-libs-dev wants to resurrect a 2011 idea and allow method references as annotation element values (JLS §9.6.1) - which would let frameworks like Spring or JUnit replace brittle, runtime-validated String literals with compile-time-checked MyClass::myMethod. A nice step in the ecosystem’s long “de-Stringification.” There’s also a JEP draft to deprecate the java.sql.rowset module for removal - ~60 commits since 2017, high maintenance cost - which triggered the predictable “but I use CachedRowSet in tests” pushback. The eternal struggle between trimming the JDK and the niche tools people quietly rely on.

The race to make the JVM an AI host is sasily the most crowded topic of the month. The strategic signal: JDK 27 planning named generative AI as one of its main pillars, with talk of tuning the runtime for vector cognitive-computing patterns and high-throughput LLM orchestration - a deliberate “Java wants to be a full AI host, not just a deployment target for Python” declaration.

The proof-of-concept layer is filling in fast. Qxotic.ai uses Project Panama (JEP 454, FFM API) to talk to native inference engines like ONNX Runtime and llama.cpp directly - no JNI glue - and combines that with GraalVM Native Image for sub-100ms startup, building the case for local LLM execution on the JVM with type-safe model orchestration.

There are also two “redesign the architecture for LLMs” projects I’m bundling together because they’re the same idea from opposite ends: Carrier is an AI-first backend compiler that turns natural-language or JSON specs into idiomatic Spring Boot 3.x (Spring Data JPA, entities, controllers, synced migrations), while Aifei by James Zhan of JFinal goes the other way - a deliberately minimalist framework of 3,333 lines and zero dependencies that collapses Controller/Service/Repository/Mapper into a single “Just Service” specifically to raise “attention density” and keep the entire LLM context window aimed at business logic. Seniors will (rightly) shudder at the abandonment of separation of concerns, but both are honest attempts at designing for how agents actually reason. I’m skeptical and curious in roughly equal measure.

JetBrains continuing its “let’s turn everything into an agent” campaign, shipped an agent skill for debugging flaky tests that orchestrates the actual JVM debugger and test runner across iterations to hunt race conditions and environment leaks - agentic workflows grounded in real execution state, not static guessing. This plugs directly into their 2026 “dual-workflow” roadmap, which leans on IntelliJ’s existing static analysis engine as a real-time verification layer against LLM hallucinations, plus a local-first approach to privacy. The Codex hackathon finalists showed where the practical wins are: AST-aware context pruning to cut token waste and hallucinations, LSP-based validation of generated code, and reasoning-trace sidebars so the agent’s logic is auditable. The recurring lesson across all of this is the same one I keep coming back to in the book - the value isn’t the model, it’s the deterministic harness you wrap around it.

And as an antidote to all the optimism: Markus Eisele Spiderweb Model for quantifying Java modernization. Instead of counting lines of code, it scores six axes - Scope, Semantics, Knowledge Opacity, Integration/Data, Feedback Friction, Governance - and his sharpest insight is that it’s Knowledge Opacity (undocumented “tribal knowledge” debt) and Feedback Friction (slow, brittle CI/CD) that actually sink AI-assisted migrations. LLMs translate syntax beautifully; they won’t conjure up missing test coverage or solve an architectural constraint nobody wrote down. Required reality check for anyone selling “just point an agent at the monolith.”

The JVM is finally good at scripting, and Haoyi Li overview breaks down the three-way race: Java shedding ceremony through JEP 330, 463, and 477 (single-file execution, unnamed classes, implicit imports); Kotlin’s .kts with @file:DependsOn; and Scala CLI, arguably leading on DX thanks to using directives plus GraalVM Native Image killing the 100-200ms startup tax. Mill 0.12 wires it into tooling. The choice is now genuinely a trade-off question, not a “is this even possible” one.

On Wasm, a good landscape survey on r/java: TeaVM (WasmGC) and CheerpJ for compiling to Wasm, GraalWasm and the pure-Java Chicory for running Wasm inside a JVM as sandboxed plugins. The missing piece remains a standardized Component Model - serialization overhead at the JVM/Wasm boundary is still costly - and the community sees Project Babylon and Leyden as precursors to any official integration. Pair this with Kotlin/Wasm going Stable (Section 0) and this year’s Wasm story suddenly has legs.

A few more, rapid-fire: Scala SIP-80 proposes a Swift-style target-typed companion shorthand (.Member) and immediately triggered the “feature fatigue / freeze the language and fix 3.6.x stability first” debate that’s worth reading as a snapshot of current Scala mood.

Netflix open-sourced Nebula ArchRules, a Gradle plugin that scales ArchUnit by decoupling rules from the test lifecycle and running them as tasks bound to check, with three-tier (error/warning/info) granularity.

The IntelliJ Platform is pushing plugin authors toward a Remote-Development-ready split (headless backend vs. JetBrains client UI, ClientSession API, EDT discipline), while the fun community library swing-fluid-swipe uses JNI into AppKit’s NSEvent to bring smooth trackpad gestures to Swing on macOS.

And a benchmark of 4 million AWS Lambda invocations confirms that SnapStart pulls Java 21 cold starts down from a brutal 1,200–4,500ms to 400–600ms (at 512MB+) - effectively neutralizing Go’s and Python’s edge, although Rust’s sub-50ms still reigns. SnapStart is now a genuine alternative to Native Image if you want to keep standard JVM ergonomics in serverless.

And to close the section on a human note: the community is worried about preserving the Java Developer Journal and Dr. Dobb’s archives from the early-2000s J2SE 5.0 era, because Sys-con Media never maintained accessible digital copies. Former JDJ editor Joseph Ottinger confirmed that the physical magazines may be the only surviving record.

There’s something on point about an ecosystem so obsessed with backwards compatibility realizing that its own written history is rotting. If you have a box of those issues in the attic - scan them.

2. Release Radar

Micronaut 5.0.0 GA

Micronaut 5.0.0 went GA - the first major in three years, and deliberately a stabilization release rather than a feature dump. The center of gravity is a unified Platform BOM that syncs every module to kill version drift - which matters enormously for reproducible AOT compilation on GraalVM - on a JDK 17 base.

On the Core side, 5.0 adds a programmatic Retry and Circuit Breaker API going beyond the declarative annotations, fixes native-image initialization for “loom-carrier” threads in GraalVM 25, and ships a new Async HTTP Client. Two breaking changes worth catching: the YAML media type moves to application/yaml, and BeanIntrospectionModule is gone - read the migration guide before jumping from 4.x.

WildFly 40 GA

WildFly 40 went GA on May 21 (Brian Stansberry), and it’s a more significant release than the round number suggests.

The headline: the standard distribution moves to Jakarta EE 11 - after incubating in a Preview variant since WildFly 32, EE 11 finally hits the default server, so you get Jakarta Data backed by Hibernate Data Repositories, Jakarta Persistence 3.2 improvements, and virtual threads in Jakarta Concurrency services on Java SE 21+.

For those not yet ready to migrate, a temporary WildFly EE 10 variant appeared, and on the security front - a long-requested HashiCorp Vault integration feature pack. This ties in nicely with the Jakarta EE 12 thread from Section 1: the spec keeps moving, and the servers are just now shipping the previous edition.

Payara → Azul Payara Community

Payara Platform Community is becoming Azul Payara Community, moving under Azul governance and aligning its lifecycle with Azul Zulu OpenJDK and Java LTS support windows. Community builds remain TCK-compliant with Jakarta EE, but expect changes to distribution binaries and artifact naming that will trickle into your dependency management and CI. More predictable long-term support in exchange for watching how the vendor model handles transparency.

Quarkus 3.35.0

Quarkus 3.35.0 shipped JAR tree-shaking, native PGO, and @Transactional support for Hibernate Reactive - but the most interesting bit is the integration with IBM Semeru / OpenJ9 Shared Classes Cache. It’s a pragmatic middle path to faster cold starts via -Xshareclasses and multi-stage Docker builds that shift JIT warmup from runtime to build time, with a nice RSS reduction because instances share cached metadata - no closed-world constraints and full reflection retained.

And as a fun stress test of the model: Quarkus Insights #246 walks through redesigning Minecraft server infrastructure as cloud-native (GraalVM native images, Mutiny, reactive messaging) to avoid stop-the-world GC pauses. Full notes.

Hibernate ORM 7.4.0

Hibernate ORM 7.4.0 is more than a routine bump - it ships an incubating but potentially substantial StateManagement SPI along with two annotations built on top of it: @Temporal for mapping temporal data and querying by “effectivity” over time (an effectivity-columns table or a split between current and historical data, transparent to client code) and @Audited for tracking modifications in a separate audit log.

There’s also a migration guide worth reviewing - among other things, on Oracle the HQL current date/local date expressions now translate via trunc(). If you’ve ever rolled your own temporality or Envers-based audit - take a look before you add another custom one.

Apache Fory 1.0.0

Apache Fory 1.0.0 - the high-performance multilingual serialization framework (you’ll remember it as Fury) hits 1.0, and in this case it’s a real milestone: from this version on, binary compatibility is guaranteed, and the unified xlang type system becomes the default mode across all languages (compatible-mode reads, simplified field ordering, better list/array compatibility).

decimal and bfloat16 support for xlang join in, and on the JVM side: Kotlin gets xlang, KSP, and IDL schema support, while Java gets Android serialization and annotation processor support. 84 PRs from 11 contributors. For anyone who’s measured serialization cost on a hot path, worth benchmarking against Protobuf or your current setup.

JUnit 6.1.0

JUnit 6.1.0 continues the 6.x line with a few genuinely useful items. The most interesting for large suites: a new WorkerThreadPoolHierarchicalTestExecutorService for parallel execution backed by a plain thread pool instead of ForkJoinPool, plus an experimental memory-cleanup mode (junit.platform.execution.memory.cleanup.enabled) useful for massive test counts.

There’s also the ability to redirect XML events from OpenTestReportGeneratingListener to a socket instead of a file. If you’re tracking the JUnit 6 migration (Keycloak’s new test framework targets it, for one) - keep this on the radar.

JobRunr 8.6.0

JobRunr 8.6.0 - the background jobs library that increasingly doubles as infrastructure for agentic stacks (recall ClawRunr built on top of it). 8.6.0 adds full JDK 26 compatibility, official Quarkus 3.33 LTS support, performance improvements for recurring jobs and SQL table validation, and - practically useful for agentic patterns - the ability to set a timeout for jobs waiting for an external signal, so they don’t hang indefinitely.

LangChain4j 1.14.0

LangChain4j 1.14.0 - the workhorse of the JVM AI stack keeps iterating. Beyond bug fixes and dependency bumps, there’s a new IMMEDIATE_IF_LAST attribute in the ReturnBehavior enum (returns the result of the AI service execution loop when a given tool is the last one in the LLM’s response) and an OpenAiOfficialResponsesChatModel class, closing the pair with its streaming counterpart for OpenAI’s Responses API.

A line in which the “resilient, stateful agents as baseline” trend is still visible.

Apache NetBeans 30

NetBeans 30 is out - the IDE that quietly keeps shipping solid, on-time releases for the part of the community that never left it. Details in the changelog, but if you’re in the NetBeans camp, this is a standard “upgrade and move on.”

JReleaser 1.24.0 / Ujorm 3.0.0 / Bob v0.7.0

Three smaller items: JReleaser 1.24.0 for release automation adds Zernio to the announcer list and a reproducible flag to enforce reproducible output; Ujorm 3.0.0, a lightweight ORM, hits major; and Bob v0.7.0 is a lightweight builder generator for Java for those allergic to annotation processors.

3. GitHub All-Stars

Four community projects that aren’t formal releases but are too interesting to lose.

Jacobin - a JVM written in Go

Jacobin is exactly the type of project that keeps me humble: a full reimplementation of the JVM in Go, targeting the Java 21 spec - and it’s not a toy. It handles invokedynamic, CONSTANT_Dynamic, sealed classes, and records via its own class-file parser, runs modern class files without a local JDK, and delegates memory management to Go’s GC instead of building its own heap.

It’s a strict interpreter with no JIT, so it won’t threaten HotSpot on throughput - but as a clean-room, OpenJDK-independent execution engine, it’s a genuinely valuable lens on how the JVM instruction set actually works. The kind of repo I’ll be pointing people at when they want to understand class loading rather than just trust it.

Strange - pure-Java quantum simulation

Strange by Johan Vos is a pure-Java API for quantum computation and a state-vector simulator - qubits and gates (Hadamard, Pauli-X, CNOT) via a declarative DSL for circuit construction, no native dependencies, no QPU access.

Originally a teaching tool for the Manning book Quantum Computing in Action, now maturing under RedFX, it lets you prototype Grover or Shor algorithms entirely inside a standard JVM. Classical state-vector simulation obviously doesn’t scale to real quantum hardware, but as an on-ramp for Java developers to experiment with quantum logic before committing to cloud QPUs, it lowers the barrier to entry considerably.

Versionparser - zero-dependency, multi-scheme version parsing

Versionparser is the unglamorous-but-essential kind of utility: a Java 17+ library, zero dependencies, that parses, compares, and normalizes version strings across incompatible ecosystems - SemVer 2.0.0, Maven, Python (PEP 440), Debian, RPM, OpenJDK formats, plus CalVer, caret/tilde ranges, epochs, and pre-release identifiers. If you’ve ever hand-rolled version-comparison logic and watched it die on a Debian version with an epoch prefix, you know exactly why a unified Version interface with no transitive dependencies is worth bookmarking - perfect for dependency scanners and build-system tooling.

Benetto - private on-device transcription on Android

Benetto (1.0.0, MIT) is a Kotlin Android app that runs whisper.cpp locally for voice transcription in 99+ languages - zero outbound network traffic, zero API cost. It uses the Whisper “Small” model (~466MB - an obvious disk-space hurdle), cleanly separates the AudioRecord-based recording module from the inference engine, and persists everything through Room.

As a reference for wiring high-performance C++ inference into Kotlin/Android internals, and as a response to data sovereignty concerns around cloud transcription APIs, it’s a tidy demonstration of where on-device ML has arrived.

PS: Fresh off KotlinConf ‘26 in Munich as a media partner - I wasn’t there myself, but the representation was solid - thanks to Grzegorz Król for the running updates. Hence this fairly Kotlin-centric edition; no regrets.

Welcome to another edition. This week it’s all about the ecosystem internals - lots of movement on both the GraalVM and OpenJDK fronts. And interestingly, these two threads are starting to intertwine - so let’s begin with the biggest organizational shift.

1. GraalVM Overhauls Its Delivery Model - and Amazon Fights for JVMCI’s Future

GraalVM is making a fundamental change to its delivery model on two fronts simultaneously. First, the project drops its independent versioning (remember those confusing 22.3, 23.0 numbers?) in favor of JDK-aligned labels like “GraalVM for JDK 21,” following the JEP 223 scheme - though this had already been creeping into the naming for a while. Second - and this is the bolder move - GraalVM shifts from quarterly to monthly feature releases.

The main driver is - of course - the need to ship AI-targeted compiler optimizations faster (hehe) along with developer tooling improvements. For JVM engineers, this means a much shorter feedback loop, especially around Native Image and polyglot environments. On the flip side, it forces a strategic choice: adopt the monthly cadence and get incremental functional iterations, or stay on quarterly CPU (Critical Patch Updates) and miss the latest optimizations. In other words, GraalVM is creating two tracks: a “fast lane” for teams that can keep up with testing, and a “stability lane” for those who prefer the proven quarterly security patch cycle. Sound familiar? It’s the same dilemma OpenJDK solved with its feature release / LTS split - just on a far more compressed timescale.

Because in 2026, everything is faster. At this rate, by 2028 we’ll be doing daily releases.

On the technical side - under the GraalVM Free Terms and Conditions (GFTC), advanced performance optimizations and G1 GC support, previously locked behind the Enterprise paywall, are now available in the free distribution. This significantly lowers the barrier for production Native Image deployments. If someone ever told you “GraalVM Native Image isn’t production-ready without Enterprise” - that excuse just expired.

There’s also a notable caveat in the roadmap: GraalVM plans to skip support for JDK 26, 27, and 28 (non-LTS versions), targeting Java 29 directly. For teams still on the 22.3.x line, this is a clear signal to migrate to a JDK 17 or 21 baseline - sooner rather than later. Aggressive sunsetting of older branches combined with an accelerated release cadence creates pressure not every enterprise will be ready for.

And it’s precisely in this context that a parallel discussion deserves attention - JDK-8382582, proposing the removal of the experimental JVMCI (Java-Level JVM Compiler Interface) from OpenJDK. HotSpot maintainers argue, not unreasonably, that JVMCI introduces significant codebase complexity and testing overhead for a feature that remains niche outside the GraalVM ecosystem.

Makes sense, right? The problem? Amazon has formally opposed it. This isn’t sentiment - their engineers report heavy reliance on Graal JIT and the Truffle framework to scale polyglot applications in production on HotSpot. And this is no small player - we’re talking AWS-scale, Corretto, and the entire ecosystem Amazon builds around the JVM.

To understand the stakes, a quick step back. JVMCI is an experimental API introduced in JDK 9 that opens HotSpot’s internal compilation pipeline to external implementations. Normally, when HotSpot decides a code path is “hot” enough for native compilation, it hands it to one of its built-in compilers: C1 (fast compilation, less optimization) or C2 (slower compilation, aggressive optimization). JVMCI lets you plug any Java-written compiler into that slot - and that’s exactly how Graal JIT works. Instead of C2, HotSpot passes the code’s intermediate representation to the Graal compiler via JVMCI, and Graal returns compiled machine code. This is what lets you run Graal as a drop-in C2 replacement on stock OpenJDK - no full GraalVM distribution needed.

JVMCI is also the foundation for Truffle - the framework that lets you implement interpreters for new languages (JavaScript, Python, Ruby, R, LLVM bitcode) and automatically get JIT compilation through partial evaluation. Without JVMCI, the entire “polyglot on HotSpot” model stops working.

The community points to Project Detroit as the “eventual successor” for JIT integration, but Amazon counters that Detroit is years from production-grade performance and stability. This isn’t a “just migrate” situation - we’re talking about live stacks serving real traffic. In a significant move, Amazon has offered to assume JVMCI maintenance responsibilities (!) - no small commitment in the OpenJDK world.

If JVMCI disappears before Detroit matures, organizations running Graal on HotSpot face a choice: GraalVM CE or a compiler stack refactor. Neither is painless.

2. Project Valhalla: From Erasure to Specialized Generics

A deep-dive article appeared on inside.java - Beyond Erasure: Project Valhalla’s Path to Specialized Generics - and it’s probably the best explanation to date of where Project Valhalla (JEP 401/402) is heading and how it plans to get there.

I know, I know - “Valhalla is coming” is a running gag in JVM circles, right up there with “year of Linux on the desktop.” But this article shows we’re dealing with something far more concrete than another promise.

The piece starts with the problem we all know: type erasure - the 2004 compromise that gave us generics but no type information at runtime. Today, C2 manages with Class Hierarchy Analysis (CHA) to eliminate redundant checkcast and speculative devirtualization. It works... okay. But it’s patching, not solving.

The article details the “Parametric VM” architecture - a fundamentally different approach to generics. Instead of erasing type information at compile time and hoping the JIT can recover it, the Parametric VM introduces a runtime “Specializer” that generates dedicated class variants for specific memory layouts. Think of it as the JVM creating a purpose-built List implementation specifically for int values - not a generic List<Object> that wraps each int in an Integer box.

This is what enables “Universal Generics”: List<int> bypasses java.lang.Integer boxing entirely. Primitives are stored directly in arrays and object fields, flattened inline alongside regular objects - no object headers per element, no pointer indirection, no chasing references across the heap. Data sits sequentially in memory, which is exactly what modern CPUs want for cache performance. The results described in the article reflect this: 60–80% memory footprint reduction and significantly improved L1 cache hit rates. Approaching C++/Rust performance territory while keeping managed runtime safety guarantees. The numbers speak for themselves.

And lest this sound like just theory and conference talks - PR #31120 has been opened with the JEP 401 implementation (Value Classes and Objects). The scale is impressive: ~3,000 commits, ~2,000 modified classes.

Before you start planning a migration, though - Brian Goetz cautions against timeline optimism. Given the mid-June rampdown and the rigorous security reviews required for such a fundamental type system change, JDK 27 is an unlikely integration target. But the sheer fact that this RFR exists - at this scale - represents the most significant movement toward flattened memory layouts in Java’s history. After a decade of waiting, I see light at the end of the tunnel. And this time it doesn’t look like an oncoming train (heh).

3. JDK 27 Early Access

JDK 27 EA is shaping up as a release worth serious attention - especially for production quality-of-life. It’s not a single-headline release (that’s still waiting on Valhalla), but the sum of individual JEPs tells a remarkably coherent story of modernizing JVM defaults. Let’s walk through the highlights, because a lot of detail has landed recently.

Memory First: G1 Everywhere + Compact Headers

JEP 523: Make G1 the Default Garbage Collector in All Environments retires the “server-class machine” heuristic dating back to J2SE 5.0 (yes, 2004 - same era as type erasure, appreciate the poetry). Until now, the JVM on machines with <2 CPUs or <1792MB RAM defaulted to the Serial Collector - which in the era of micro-containers with 512MB RAM limits meant a good chunk of production workloads got a GC never designed for them. G1 is now the default everywhere. No more GC log surprises after deploying to Kubernetes with aggressive resource limits.

In parallel, JEP 534: Compact Object Headers by Default enables compact object headers by default. Building on JEP 450: Compact Object Headers (Experimental), this reduces the standard object header from 12 to 8 bytes on 64-bit architectures by encoding the class pointer into the mark word. Sounds like an implementation detail? Perhaps. But for workloads that create lots of small objects (and which Java workload doesn’t?) it’s a 10–20% heap reduction and better CPU cache performance - out of the box, no flags needed.

It’s fascinating how quickly that one got from the concept to production default.

Security: JFR Finally Stops Leaking Your Secrets

JEP 536: JFR In-Process Data Redaction brings in-process data redaction to JDK Flight Recorder. And I have to say it bluntly: finally.

For years, JFR has been an invaluable production profiling tool - low overhead, rich telemetry, no external agent dependencies. But it carried a dirty secret (pun intended): database passwords, API tokens, and auth keys passed via environment variables or system properties ended up in .jfr files as plaintext. Anyone who’s ever run a security audit at an organization using JFR knows the moment - “wait, these credentials have been in diagnostic files... for two years... on a shared network drive?”

Redaction now operates at the JVM recording engine level - before data hits disk or gets emitted via the JFR Streaming API. Three targeted events: jdk.InitialSystemProperty, jdk.InitialEnvironmentVariable, and jdk.JVMInformation (command-line arguments). The shift from “redact after the fact” to “secure by default at source” is a major compliance win - especially for GDPR, SOC2, and similar regulations. It eliminates the need for custom sanitization scripts that - in my experience - half of teams forgot to configure on new environments anyway.

The only minor cost: debugging configuration issues that require seeing full property values gets slightly harder. But that’s a trade-off most enterprise architects will accept with open arms.

Diagnostics: jcmd Learns to Read Core Dumps

JEP 528: Post-Mortem Crash Analysis with jcmd extends jcmd with post-mortem analysis - finally letting you run familiar diagnostic commands (Thread.print, VM.info, VM.flags, VM.system_properties) against static core files from HotSpot crashes. Syntax: jcmd <executable> <corefile> <command>.

For those of you who’ve never had to reach for jhsdb at 3 AM during a production incident - congratulations, I wish you continued luck. For the rest of us - this bridges the gap between the friendly, well-known jcmd and the more complex, Serviceability Agent–based jhsdb. Until now, jcmd only worked with live JVM processes (PID or local socket). If the process died and left a core dump, you had to switch to a completely different tool with different syntax, conventions, and mental model. In containerized environments where JVM processes are ephemeral, this is even more painful - by the time you’d attach jcmd, the container was long recycled by the orchestrator.

JEP 528 doesn’t replace jhsdb (still essential for low-level memory inspection) or native debuggers like GDB. But it surfaces the most commonly needed JVM metadata through the standard, familiar interface - a significant convenience for production support and root-cause analysis.

macOS/x64 Deprecation: End of an Era

Oracle has officially signaled the end of macOS/x64 port maintenance - deprecation targets JDK 27, with eventual removal to follow. The argument is straightforward: Apple Silicon won, the transition succeeded, and maintaining the legacy Intel port demands full-time dedicated engineering that’s no longer justifiable.

Worth emphasizing - Oracle explicitly stated this is not a part-time job. It requires dedicated resources for feature parity and platform-specific bug fixing. The bar for a “credible third-party” successor is high, and no one has stepped up yet. The community is largely pragmatic about it - some voices suggest aligning JDK’s support window more closely with Apple’s own macOS x64 hardware lifecycle, but realistically, JDK 27 will likely be the first release where Intel Macs become legacy tier.

If you’re still relying on Intel Mac Pros or x64 macOS CI/CD runners - time to plan the migration. AArch64 macOS or Linux x64 environments are the two obvious paths.

Re-previews and Incubations: The Eternal Stabilization

Finally - the “eternal candidates,” each at a different point on the road to GA, but all sharing the same theme: the API is ready, the integration isn’t.

Structured Concurrency (JEP 533) enters its seventh(!) preview - easy to lose count since the feature has been evolving since JDK 19 (JEP 428). The main change this round is an API refinement toward fluent style: StructuredTaskScope.join() and joinUntil(Instant) now return the scope instance, enabling elegant chaining in try-with-resources blocks. Cosmetic? Perhaps. But it signals that core mechanics are settled (the major refactor happened in JDK 24/JEP 491) and the team is now polishing ergonomics. Seven previews suggest a cautious approach to API stability - which, after experiences with “premature GA” features (see: Nashorn), is welcome.

Vector API (JEP 537) hits its... twelfth incubation. Yes, twelfth. The API is effectively frozen - zero breaking changes this iteration - but graduation awaits Valhalla and its value classes with specialized generics. Without those, the Vector API can’t reach its final, memory-overhead-free form. For those already using SIMD via jdk.incubator.vector in production (with the --add-modules flag): nothing changes, your code will keep working.

Lazy Constants (JEP 531) in its third preview stabilizes a lazy initialization mechanism that lets HotSpot recognize and optimize lazily computed values as aggressively as static final - constant folding, inlining, the full arsenal. For years, developers relied on the “initialization-on-demand holder idiom” or volatile double-checked locking; these patterns work for concurrency but remain black boxes to the JIT. JEP 531 offers a declarative alternative that communicates semantics directly to the compiler. Third preview signals stabilization.

And finally JEP 538 PEM Encoder/Decoder - native PEM support in the Java Cryptography Architecture, handling PrivateKey, PublicKey, X509Certificate, and X509CRL. The most interesting technical detail: streaming-capable processing for efficient handling of large Certificate Revocation Lists without memory pressure. No more manual Base64, no more depending on Bouncy Castle just to handle RFC 7468.

Closing Note: The Lazy Collections Debate (JEP 526)

An interesting debate is brewing on amber-dev around JEP 526 (”Deferred Immutability”), worth watching even if it doesn’t land in JDK 27. The proposal introduces List.ofLazy / Map.ofLazy with mandatory memoization - simplifying immutable collection creation with on-demand computed values, thread-safety guarantees, and “compute-once” semantics.

The community, however, points to a serious limitation: hardcoded memoization prevents these APIs from serving as truly lazy functional views - à la Guava’s Lists.transform. The core objection? If every value must be memoized, you can’t handle collections larger than available heap, and simple type conversions (e.g., projecting a List<CharSequence> as List<String>) force unnecessary allocation. The debate centers on whether these methods should be simple convenience utilities for late-initialized data or a broader foundation for memory-efficient data processing. Consensus leans toward a non-caching default - and frankly, I agree.

----

PS: And greetings to all those in the KotlinConf. I couldn’t make it this year. However, my special reporter, Grzegorz Król, will bring you some news from the conference!

This edition will be shorter than usual. I’ve been travelling a lot, I’m on a conference tour, and this week I managed to squeeze in the Code Remix Summit organised by Moderne. So instead of the usual news roundup - a postcard from the conference, with short teasers for the talks worth catching up on via the recordings once they’re up.

Because it’s worth saying upfront: I was there on my own dime - well, okay, on VirtusLab dime, on the picture up there I’m with Tomasz Orzechowski, our COO - without an invitation from Moderne , without a “write something nice about us” contract. We were just curious about what was going on. And I have to say, it was worth it. Sincere feedback, not sponsored content.

Code Remix Summit was very focused - and that’s a big plus for me. The whole conference revolves around one theme: scaling code changes. OpenRewrite, automated migrations, agentic refactoring, tooling for agents. No blockchain, no microservices-vs-monolith panels. Each talk connects to the previous one, in the hallways you bump into people who actually understand your problems with a 4-million-line codebase, and after you come home you have a coherent map instead of a random bag of ideas. In a world of “a bit of everything” conferences (which I do enjoy, by the way) - this kind of change of pace makes a difference.

OK, let’s get to it. I’m going in order, so if any of the talks catches your eye, you’ll easily find it on the playlist once it shows up (if I understand correctly how this will work).

1. “Making Changes at Scale” - Morgan Stanley

The opening of the conference. Dov B. Katz and Khalid Elsawaf from Morgan Stanley - a year of experience with OpenRewrite and Moderne in production. Very often, keynotes at conferences like these are dull. Either they go full “transformation, future, paradigm shift”, or they dive into a granular demo that no one has the head for in the morning. I especially liked quote, that this is a first time work in Software Engineering (Code Review) shifts right. Thant’s very interesting insight.

This one hit exactly the middle - lots of concrete ideas, zero pretending they’ve already solved everything - and a fair bit of riffing on the now-popular “code is cheap, software engineering is still expensive”. A perfect rhythm for the opening.

Slides

2. “Diff Risk Score: AI-Driven Risk-Aware Software Development” - Meta

Rui Maranhao Abreu talked about Meta’s DRS - a model that predicts whether a given diff is likely to cause a customer-facing incident. Meta has wired this signal into the entire SDLC: from review, through testing, all the way to automated rollback plans.

What sold me the most was the part on Centrality - a graph of how a change ripples through the rest of the codebase, used as a model feature. Once again you can see that graphs are increasingly the core of developer tooling.

Bonus insight: figuring out which signal actually predicts risk - versus which one just looks pretty on a slide - is genuinely interesting work.

3. “Feature Flags: How to Ship Faster, Safer, and Smarter” - Wells Fargo

Dinesh Arora session was a bit more basic. What feature flags are, FF4J/Togglz in the demo, best practices. After the Meta and Morgan Stanley sessions - it’s a step down in complexity. But it was still interesting to hear what deployment challenges are showing up in banking. Wells Fargo has its own, very specific risk landscape, and that perspective made for a nice counterpoint.

Slides

4. “How Uber Migrated 75K JUnit4 Test Classes to JUnit5 Using OpenRewrite” - Uber

Anshuman Mishra and Kaushik Vejju - one of those sessions you go to conferences for if you’re into large-scale transformations. End-to-end, top-to-bottom migration: 75 thousand test classes, 400 thousand tests, 15M+ lines of code, 1.5M modified. Customisations for Uber’s monorepo, validation, rollout safety, CI integration. No magic, with concrete numbers. Anyone who’s ever tried something like that in their own organisation knows what I’m talking about.

Definitely worth at least flipping through the slides.

5. “Agentic Coding at Airbnb” - Airbnb

Szczepan Faber - yes, the Mockito creator, currently Engineering Leadership at Airbnb - on how they brought agentic coding into a monorepo with tens of millions of lines of code. Applications that have to be secure and compliant. Trade-offs, learnings, productivity impact. A very pragmatic approach to most of the problems - some things they have solved, some are still open, and they say so openly. A general overview of “how it’s done at Airbnb”. Refreshing.

Slides

6. “Shepherd: How We Handle Uber-Scale Migrations at Uber” - Uber

The gem of the conference. Anshuman Chadha and Sung Yoon Whang showed off Shepherd - Uber’s migration platform. 4.3M lines of code reworked, 30,000+ diffs across five monorepos, migrations going from “quarters of manual coordination” to “weeks with observability”. Deterministic compiler-aware transformations + AI-assisted remediation + ownership-aware routing + integrated validation.

I walked out of the session and immediately started looking for Shepherd-like solutions in the open source world - and I didn’t find any. This is exactly the level of abstraction where tools are missing today.

If you’ve got tokens to burn, you know what to do with them.

Slides

7. “Netflix’s Journey to Confident Automated Changes” - Netflix

Roberto Pérez Alcolea 🇲🇽 and Aubrey Chipman (what an energy, loved that!) showed how Netflix built a platform for deploying automated changes across thousands of repositories. The emphasis was on developer trust in automation: shift-left validation, feedback loops, impact analysis.

A few good ideas - for me mostly the thread around MCP as an interface to all this machinery, and the “beyond basic” skill repository.

Oh, and the slides were just fantastic design-wise, straight out of Wynwood Walls.

8. “Upgrade Your Java with AI: From Legacy Code to High-Performance Workloads” - AWS

Closing out my list. Vinicius Senger and Jonathan Vogel (both Senior Developer Advocates at AWS) - tying AI-assisted refactoring of legacy Java together with runtime analysis (Java Flight Recorder), a workflow built on top of Embabel agents. So not just “AI changes the code”, but also “AI checks whether the changed code actually runs faster in production”.

That missing loop - modernisation → measurable performance - is what a lot of tools still don’t have. Nice to see someone trying to close it. There’s a practical implementation - embabel/modernizer - to clone and play with on your own.

On top of that, if you remember Jonathan’s pieces from my “Rest of the Story” editions, here you could see the results of the research in practice... with a few extra goodies ready for part three 😁

Now a word about Moderne itself

After three days of listening to how Meta, Uber, Netflix, Morgan Stanley and Airbnb are putting OpenRewrite to work on production migrations, one common thread emerges. And this, in my view, is Moderne’s most important ideological move.

In a world where everything is heading toward the probabilistic - LLMs, agents, “maybe it’ll work, maybe not, but give it a shot” - Moderne is going against the grain. Deterministic, compiler-aware code transformations as the foundation. AI as a remedial layer where determinism ends. Not the other way around.

And that is a hugely healthy distribution of responsibility. If you know that a given refactor will always produce the same result on 4.3M lines of code - you can run it overnight without staring at the terminal. If you know an agent has bad days - you don’t want it deciding whether @RunWith gets swapped for @ExtendWith. Each of these talks - Meta with DRS, Uber with Shepherd, Netflix with their observability - was effectively about finding that boundary. Where does the deterministic part of the migration end, and where does “this is where the LLM has to step in” begin.

And this isn’t an idea that belongs to Moderne alone. Google has their Rosie - described in detail in Software Engineering at Google, and in the original Potvin/Levenberg CACM paper about the monorepo. Uber has Shepherd in a company-specific variant - the same piece from Anshuman Chadha’s talk, the same one they used to drive the JUnit 4 → 5 migration (orchestrating diffs across thousands of Bazel targets). Sourcegraph has been growing their Batch Changes since 2021, with changelog updates still going strong in April 2026.

And I have to admit - one of the bigger lessons from this trip was realising how much of this is out there in the industry. Listening to one talk after another, you can see that practically every organisation above a certain scale threshold has built its own variant of a large-scale-changes orchestrator. Most of them don’t have the motivation to talk about it publicly. And that’s exactly why a conference like Code Remix makes a difference - it’s one of the few moments in the year when these internal tools come out into the light.

The organisational problem of scaling changes can’t be solved with LLMs alone. LLMs are great at writing code. They’re poor at predictably repeating the same change 30,000 times in a row and reporting what went wrong.

Moderne is turning this into a product for the whole industry. Take Prethink - the concept is charmingly simple: instead of letting Claude search the codebase using tokens at runtime (expensive, slow, non-deterministic), you precompute a map of the system first. A set of OpenRewrite recipes generates data tables from the LST, the full dependency tree including transitive ones, an optional knowledge graph, plus architecture diagrams in FINOS CALM and Mermaid format. The result lands in CLAUDE.md and associated files - and the agent has it at hand before it even starts writing.

The open-source component lives under openrewrite/rewrite-prethink.

A small detail that closed the loop for me after I got back: CALM - that format Prethink uses for architecture diagrams - was open-sourced by Morgan Stanley in August 2025. The same firm that opened Code Remix with a talk about its year with OpenRewrite. The whole ecosystem is growing together, and you can see it.

Moderne’s cleanest framing goes like this: we’re shifting work from GPU inference to CPU precomputation. Cheap, deterministic calculation in the background. Expensive, probabilistic decisions in the foreground. And Prethink is the tangible form of that idea - something you can pull from GitHub and run today.

There’s also the community angle. Because just like with JobRunr - it’s really nice to see another generation of products growing out of Java open source. JobRunr grew from a library into a solid platform with a commercial variant. OpenRewrite grew from a little refactoring library into Moderne - a whole infrastructure for agents, an agent-tools company, as they now call themselves. This is exactly what the JVM ecosystem needs. Good patterns.

Cheers, Moderne team. Jonathan Schneider Rooz Mohazzabi Paula Paul Tim te Beek Matt Finkelstein Robert Sobieski (Poland strong!) Jaida Olvera Alters Antony Austin Jente Sondervorst and all the rest - it was a great job 😊

Also, I loved the dog - it was charming.

PS: I still remember the party at Devoxx Belgium 2024, BTW 😊

Whether you use OpenRewrite or not - “what’s deterministic and what’s probabilistic in my pipeline” is the question every mature developer platform will be asking itself in 2026.

-PS: A really nice moment - completely by chance I bumped into Jonathan Vogel in person (yes, the one from the AWS talk), who you may know from recent Rest of the Story editions. The internet is a weird place, but conferences still make a difference.

PS2: Tomorrow we’ll see each other at geecon in Kraków. I have a talk there about agentic architectures based on my Kotlin NES emulator that plays Final Fantasy I. Drop by - let’s chat in person.

PS3: From the JVM Weekly in Strange Places series: Miami Airport.

As a hub for the “Friends of OpenJDK,” Foojay.io continues to be one of the better places to track what is actually happening in the JVM ecosystem month-to-month. And this month I want to start with a piece that has been sitting on my “must cover” list since it landed.

This month’s main feature comes from David Vlijmincx, Senior Java Developer and Oracle Ace, who has been quietly writing one of the more useful FFM API series I’ve come across. His earlier piece on Arenas, malloc, and custom pools covered the spectrum from Arena.ofConfined() (safe, scoped, easy) to raw malloc/free via FFM (you’re basically writing C now). What that piece didn’t tackle is what happens the moment you create a MemorySegment that more than one thread can see - which is exactly what the next installment goes after.

I want to focus on this one because it tackles the problem most FFM tutorials handwave: ARM and x86 do not behave the same way under contention, and your code is going to ship to both. Let’s dig in.

Thread-Safe Native Memory in Java: VarHandle Access Modes Explained

What is Memory Order and Why Does It Matter for Native Memory?

The Foreign Function and Memory (FFM) API is Java’s way of interacting with native code and memory. In the previous post, you learned how to do so using Java’s built-in Arena types. The Arena provides temporal safety and bounds checks, but what about thread safety? MemorySegments created by .ofShared(), .auto(), and .global() can be used by multiple threads at the same time. Using a VarHandle with just get/set can backfire if you don’t use something like locking. The downside is that locks are slow and heavy. So let us take a look at a more granular, hardware-aware approach: using VarHandle access modes.

Why do you need all of this?

When you write concurrent code, you rely on the hardware to keep things in sync. Different CPU architectures handle memory ordering differently. On x86, the memory model is relatively strong. Reads and writes are mostly kept in order, meaning you can often get away with loose synchronization. ARM, however, has a weak memory model. The CPU is free to reorder reads and writes aggressively to optimize performance. If you write code assuming x86’s strict ordering and run it on an ARM processor (like Apple Silicon or AWS Graviton), your application will break in unpredictable ways. VarHandle has methods that help with these situations to make sure your code works everywhere.

To see exactly how these mechanics work, we will start with the least restrictive access mode and build our way up to a full memory fence. But before we do that, I want to show you how to actually test this.

Testing it using JCStress

Java Concurrency Stress is an experimental harness that helps you test the correctness of your concurrent code. It does this by running your test concurrently, accessing the same shared state. During execution, it collects the results of the observed state. The goal is to see how your code got rearranged and/or optimized and how it affected the state. One of the ways it does this is by running each thread using a different compilation mode like: interpreter, C1, or C2. JCStress tests each combination of compilation modes (interpreter, C1, C2) across the actors. With two actors, that’s nine combinations per run.

Creating these tests requires a bit of a different mindset. Normally, you want two threads to play nicely. Inside the JCStress test you want them to clash as often as possible to observe the possible states your code could end up in. This gets kind of confusing, so let’s use this example and let’s say you have two threads running the following code:

synchronized (lock) {
// What you want to test
}

If you used this with JCStress the threads would basically run synchronized one after the other. Of course, it’ll work, but it doesn’t prove anything. So in the examples to come, keep in mind that we want the threads interleaving with each other and just hammer the state to see what happens. Just as it would in the real world. Another tip for when using JCStress is to not test too much inside a single test. You get a big state with lots of possibilities. To keep the tests fast and snappy, focus the test to tackle one synchronization/thread interleaving problem.

So what does the output look like? Like this:

RESULT SAMPLES FREQ EXPECT DESCRIPTION

-1 104,287,516 37.93% Acceptable Ready flag not seen yet.
0 1,364 <0.01% Interesting Visibility failure: saw ready flag but missed the data.
42 170,677,819 62.07% Acceptable Data seen correctly.

It shows the sampling results and how often they were encountered. The developer sets the expectations and descriptions, so they depend on the case.

Plain Access (Get/Set)

Plain access is the simplest mode there is. No rules or any fence! This works like any other get/set/read/assignment that you are used to in Java like var x = 1 for example. Get/Set work the same way for MemorySegments, it simply sets and gets a value. This is perfectly fine if you are working inside a single thread and don’t share your state with other threads. In this mode the compilers, CPU, and cache are allowed to optimize your code and reorder the instructions. As long as the end result looks like it executed your code as you wrote it. This illusion is true as long as you don’t create race conditions using multiple threads. So what does this look like? Let’s break this illusion with two threads and JCStress. The next example, has a shared MemorySegment that is used to communicate a ready flag and some data. One thread set the data, and the other thread reads the result.

@JCStressTest
@Outcome(id = "42", expect = Expect.ACCEPTABLE, desc = "Data seen correctly.")
@Outcome(id = "-1", expect = Expect.ACCEPTABLE, desc = "Ready flag not seen yet.")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "Saw ready flag but missed the data.")
@State
public class NativeMemoryPlainAccess {

    private final MemorySegment segment;
    private static final VarHandle VH_INT = ValueLayout.JAVA_INT.varHandle();

    public NativeMemoryPlainAccess() {
        this.segment = Arena.ofAuto().allocate(8);
    }

    @Actor
    public void actor1() {
        VH_INT.set(segment, 0L, 42);
        VH_INT.set(segment, 4L, 1);
    }

    @Actor
    public void actor2(I_Result r) {
        int ready = (int) VH_INT.get(segment, 4L);
        if (ready == 1) {
            r.r1 = (int) VH_INT.get(segment, 0L);
        } else {
            r.r1 = -1;
        }
    }
}

These threads are passing a message, one thread sets some data, and the other thread reads it. There is no synchronization or fence inside this example, so everything is free to be reordered. This is going to introduce race conditions. This table shows all the different states observed while running the code:

RESULT SAMPLES FREQ EXPECT DESCRIPTION

-1 104,287,516 37.93% Acceptable Ready flag not seen yet.

0 1,364 <0.01% Interesting Visibility failure: saw ready flag but missed the data.

42 170,677,819 62.07% Acceptable Data seen correctly.

JCStress ran the code using different combinations of compilers (interpreter, C1, C2), and as you can see we got three different combinations. Some of the time the ready flag was set, and it got the value 42, other times the flag wasn’t set. Both of these are correct states. But 0 is an interesting state... It means that the flag was set, but the data wasn’t there yet. The code got reordered! This is not a correct state to be in as 0 shouldn’t be possible, right? To fix this issue, we need Acquire/Release, but let’s look at Opaque first as it is the next mode in the hierarchy.

Opaque Access

Opaque is the odd one out. Opaque doesn’t insert memory fences and provides no ordering guarantees between different variables. What it does provide is: bitwise atomicity (no word tearing), coherence (all threads see writes to the same variable in the same order), and progress (writes will eventually become visible). It also prevents the compiler from eliminating access to that specific variable. This is handy for liveness checks, for example. Let’s say you have two threads. thread_1 runs a while loop until it gets the signal to stop. Thread_0 is in control of this signal. Without Opaque, the compiler is allowed to turn that loop into a while(true), Thread_1 would never stop. JCStress is not really made for this specific scenario, so let’s look at another example instead. In the example, Thread_1 will write 1 and 2 to the same place in the MemorySegment. Thread_2 does two reads to see the intermediate/end results. Again, the goal is to make the threads clash as often as possible.

@JCStressTest
@Outcome(id = "1, 2", expect = Expect.ACCEPTABLE_INTERESTING, desc = "Observed intermediate state reliably.")
@Outcome(expect = Expect.ACCEPTABLE, desc = "Other observable states (0,0 / 2,2 / 0,2).")
@State
public class OpaqueNativeOpaqueAccess {

    private final MemorySegment segment;
    private static final VarHandle VH_INT = ValueLayout.JAVA_INT.varHandle();

    public OpaqueNativeOpaqueAccess() {
        this.segment = Arena.ofAuto().allocate(4);
    }

    @Actor
    public void actor1() {
        VH_INT.setOpaque(segment, 0L, 1);
        VH_INT.setOpaque(segment, 0L, 2);
    }

    @Actor
    public void actor2(II_Result r) {
        r.r1 = (int) VH_INT.getOpaque(segment, 0L);
        r.r2 = (int) VH_INT.getOpaque(segment, 0L);
    }
}

The results show that even though Opaque prevents extreme compiler optimizations, it does not guarantee immediate visibility across threads. The vast majority of the time, the second actor sees either the initial state (0, 0) or the final state (2, 2). However, we also observe intermediate states like (1, 2) or ordered reads like (0, 2). Because there are no ordering constraints or memory fences, the CPU and caches can still delay when the writes from actor1 become visible to actor2. The presence of (1, 2) confirms that the intermediate write of 1 is occasionally caught in transit.

  --- OPAQUE ACCESS ---
  RESULT      SAMPLES     FREQ       EXPECT  DESCRIPTION
    0, 0  114,615,126   41.45%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    0, 1       73,653    0.03%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    0, 2      577,951    0.21%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    1, 1      283,707    0.10%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    1, 2      114,550    0.04%  Interesting  Observed intermediate state reliably.
    2, 2  160,817,232   58.17%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).

    --- PLAIN ACCESS ---
    RESULT      SAMPLES     FREQ       EXPECT  DESCRIPTION
    0, 0  125,004,639   45.55%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    0, 1       38,798    0.01%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    0, 2      311,919    0.11%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    1, 1      362,391    0.13%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    1, 2       68,803    0.03%  Interesting  Observed intermediate state.
    2, 2  148,668,149   54.17%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).

When the C2 compiler steps in, it optimizes the code heavily. With Plain access, C2 often optimizes away the intermediate write entirely, assuming it’s redundant since the final value is 2. This is why you see almost zero (1, 2) results in the Plain Access C2 table. Opaque access, however, explicitly forbids the compiler from removing that intermediate write. Consequently, the C2 table for Opaque still shows a noticeable number of (1, 2) results. The compiler was forced to keep both writes, and the hardware’s lack of fencing allowed the intermediate state to be observed.

  --- OPAQUE ACCESS  C2 ---
  RESULT     SAMPLES     FREQ       EXPECT  DESCRIPTION
    0, 0   9,721,273   34.26%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    0, 1         677   <0.01%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    0, 2      32,666    0.12%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    1, 1      17,747    0.06%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    1, 2         561   <0.01%  Interesting  Observed intermediate state reliably.
    2, 2  18,600,087   65.56%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).

    --- PLAIN ACCESS C2 ---
   RESULT     SAMPLES     FREQ       EXPECT  DESCRIPTION
    0, 0  14,047,744   50.31%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    0, 1           2   <0.01%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    0, 2         106   <0.01%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    1, 1           1   <0.01%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).
    1, 2           4   <0.01%  Interesting  Observed intermediate state.
    2, 2  13,874,594   49.69%   Acceptable  Other observable states (0,0 / 2,2 / 0,2).

So in the end, Opaque is the combination of:

• Plain access: the get and set from the section above.

• Access atomicity: Reads and writes happen as a single, indivisible unit. No word tearing, even for 64-bit types like long and double.

• Coherence: writes to the same variable are observed in the same order for all observers.

• Progress: The writes will be eventually visible.

Opaque is useful in specific scenarios but too weak for most concurrent patterns. One example that would be a good fit is a variable that you want to broadcast to other reader(s). A counter that is owned by one thread and collected by other threads would be an example of this.

Let’s go one level deeper and see what happens when you add causality to the mix.

Acquire/Release

Acquire and Release offer a stricter mode than Opaque by including all of Opaque’s guarantees and adding a happens-before relationship. This means it is stricter than Opaque, but still lighter than volatile. Release and Acquire are two separate methods:

• setRelease(): The compiler/CPU is not allowed to move a read or write instruction that happens before the Release to happen after it.

• getAcquire(): All reads and writes after this point are guaranteed to see at least the data that was visible at the point of the corresponding setRelease(). The compiler/CPU is not allowed to move an instruction that happens after the Acquire to before it.

Let’s see how these rules play out in the real world. In the following code actor1 sets three values to a MemorySegment. The setRelease is used to set a flag that the data is ready to be read. Actor2 watches the flag for a change. When it reads a 1, it fetches the data from the segment.

@JCStressTest
@State
public class HappensBeforeAndAfter {

    private final MemorySegment segment;
    private static final VarHandle VH_INT = ValueLayout.JAVA_INT.varHandle();

    public HappensBeforeAndAfter() {
        this.segment = Arena.ofAuto().allocate(64);
    }

    @Actor
    public void actor1() {
        VH_INT.set(segment, 0L, 1); // Plain writes — made visible by the setRelease below
        VH_INT.set(segment, 0L, 2);
        VH_INT.set(segment, 0L, 3);
        VH_INT.setRelease(segment, 12L, 1);
    }

    @Actor
    public void actor2(I_Result r) {
        int ready = (int) VH_INT.getAcquire(segment, 12L);
        if (ready == 1) {
            r.r1 = (int) VH_INT.get(segment, 0L);
        } else {
            r.r1 = -1;
        }
    }
}

When running this code with JCStress, I got the following results. Both results are valid -1 just means that the flag wasn’t set yet and there was no attempt to read the data. And 3 means that the data from the last write was read.

  RESULT      SAMPLES     FREQ
      -1  167,565,777   62.57%
       3  100,243,162   37.43%

Doing the same with just a plain set/get will result in the compiler and CPU reordering the code as there is no happens-before anymore. The result of running it with plain access is like this:

  RESULT      SAMPLES     FREQ
      -1  174,727,852   64.82%
       0        3,906   <0.01%
       1           75   <0.01%
       2           94   <0.01%
       3   94,828,052   35.18%

This isn’t pretty when we want to only read the data only when it is actually available. The values 0, 1, and 2 mean the ready flag appeared set before the data was actually written. This shows that Release/Acquire excels in cases like producer-consumer designs, message-passing designs.

Volatile

This is the last and strictest mode, designed to enforce sequential consistency and a total order of operations across all threads. When you use volatile, it prevents aggressive instruction reorderings. Such as a newer read bypassing an older write. Or by ensuring that prior volatile stores are drained from the hardware’s store buffer to the coherent cache before processing new loads. While it doesn’t freeze the CPU to provide instant, wall-clock visibility, it guarantees that all cores will eventually agree on the exact same sequence of events. Because every read will observe the most recently written value within that agreed-upon memory order, volatile is the safest and most reliable mode for synchronizing state across multiple variables.

@JCStressTest
@Outcome(id = "0, 0", expect = Expect.FORBIDDEN, desc = "Read visibility failure")
@Outcome(id = "1, 1", expect = Expect.ACCEPTABLE, desc = "Data seen correctly.")
@Outcome(id = "1, 0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "One actor got shuffled")
@Outcome(id = "0, 1", expect = Expect.ACCEPTABLE_INTERESTING, desc = "One actor got shuffled")
@State
public class NativeMemoryFullFence {

    public static final GroupLayout LAYOUT = MemoryLayout.structLayout(
            ValueLayout.JAVA_INT.withName("x"),
            ValueLayout.JAVA_INT.withName("y")
    );
    private static final VarHandle VH_X = LAYOUT.varHandle(groupElement("x"));
    private static final VarHandle VH_Y = LAYOUT.varHandle(groupElement("y"));

    private final MemorySegment segment;

    public NativeMemoryFullFence() {
        this.segment = Arena.ofAuto().allocate(LAYOUT);
        VH_X.set(segment, 0L, 0);
        VH_Y.set(segment, 0L, 0);
    }

    @Actor
    public void actor1(II_Result r) {
        VH_X.setVolatile(segment, 0L, 1);           // Store X
         r.r1 = (int) VH_Y.getVolatile(segment, 0L); // Load Y
    }

    @Actor
    public void actor2(II_Result r) {
        VH_Y.setVolatile(segment, 0L, 1);           // Store Y
        r.r2 = (int) VH_X.getVolatile(segment, 0L); // Load X
    }

}

The two actors are reading and writing to two different places inside the memorySegment. By using volatile, the write is guaranteed to be fully visible to all threads before any subsequent operation in this thread proceeds. This is slower but guarantees all threads agree on the order of operations.

  RESULT      SAMPLES     FREQ       EXPECT  DESCRIPTION
    0, 0            0    0.00%    Forbidden  Read visibility failure
    0, 1  142,965,429   53.47%  Interesting  One actor got shuffled
    1, 0  123,397,941   46.15%  Interesting  One actor got shuffled
    1, 1      995,009    0.37%   Acceptable  Data seen correctly.

If a weaker model like Release/Acquire is used, the CPU does not wait for the prior write to be drained to the coherent cache before executing the next read to a different address. You fire the write action and continue directly with the next read. Because each CPU is its own environment with its own physical clock, they have no clue how time is progressing on other cores. This lack of a total order means you can end up with a cycle in your memory order, observing the forbidden 0, 0 state when synchronizing across two or more variables, as shown here:

  RESULT      SAMPLES     FREQ       EXPECT  DESCRIPTION
    0, 0      205,803    0.08%    Forbidden  Read visibility failure
    0, 1  123,619,023   47.36%  Interesting  One actor got shuffled
    1, 0  136,207,596   52.18%  Interesting  One actor got shuffled
    1, 1      977,157    0.37%   Acceptable  Data seen correctly.

Release/Acquire is fine when you have a single variable that you care about, but when you need to synchronize across two or more variables, it fails and you need the stronger volatile mode.

TL;DR

Just use Get/Set and Volatile and have a peaceful life. If that’s really not enough, and you really need this fine-grained control. Maybe consider still using get/set and volatile. If I really can’t convince you, then the other modes are great for those special cases where volatile causes too much of a performance issue.

Conclusion

Working with native memory across multiple threads forces you to confront how hardware actually executes your code. While the FFM API provides a direct bridge to native memory, it doesn’t shield you from CPU reordering or cache visibility issues. Plain access is perfectly fine for single-threaded tasks, but once you share memory segments, you need to apply the right VarHandle access modes. Volatile is the safest default, providing strict ordering at the cost of performance. If profiling indicates volatile is a bottleneck, you can step down to Acquire/Release or Opaque, but you take on the responsibility of managing the memory order yourself. Always test concurrent memory access thoroughly, as architectural differences between x86 and ARM will easily expose any flaws in your assumptions.

Bonus: Word Tearing

Word tearing occurs when a read or write operation on a piece of memory is not atomic. If you write a 64-bit value to unaligned memory, or on a 32-bit system, the CPU might execute it as two separate 32-bit operations. If another thread reads that memory in between those two operations, it will get half of the old value and half of the new value. Using Opaque would prevent this from happening. For demonstration purposes let’s look at an example using unaligned memory access.

@JCStressTest
@Outcome(id = "0, 0", expect = Expect.ACCEPTABLE)
@Outcome(id = "0, 9223372036854775806", expect = Expect.ACCEPTABLE)
@Outcome(id = "0, 9223372036854775807", expect = Expect.ACCEPTABLE)
@Outcome(id = "9223372036854775806, 9223372036854775806", expect = Expect.ACCEPTABLE)
@Outcome(id = "9223372036854775806, 9223372036854775807", expect = Expect.ACCEPTABLE)
@Outcome(id = "9223372036854775807, 9223372036854775807", expect = Expect.ACCEPTABLE)
@Outcome(expect = Expect.ACCEPTABLE_INTERESTING)
@State
public class WordTearingWithPlain {

    private final MemorySegment segment;
    private static final VarHandle VH_LONG = JAVA_LONG.withByteAlignment(1).varHandle();

    public WordTearingWithPlain() {
        this.segment = Arena.ofAuto().allocate(JAVA_LONG.byteSize() * 2,1);
    }

    @Actor
    public void actor1() {
        VH_LONG.set(segment, 4L, Long.MAX_VALUE - 1);
        VH_LONG.set(segment, 4L, Long.MAX_VALUE);
    }

    @Actor
    public void actor2(LL_Result r) {
        r.r1 = (long) VH_LONG.get(segment, 4L);
        r.r2 = (long) VH_LONG.get(segment, 4L);
    }
}

The results explicitly show word tearing in action. Value 4294967294 is not the initial 0 or the intended Long.MAX_VALUE or Long.MAX_VALUE - 1. Because the MemorySegment was accessed with an unaligned layout (1-byte alignment for an 8-byte long), the JVM and CPU could not write the 64-bit long in a single, atomic hardware instruction. Instead, it was split. Actor2 managed to read the memory exactly when only half of the new value had been written, resulting in a corrupted, blended value. This highlights why alignment and proper access modes are necessary when managing memory manually.

                                    RESULT      SAMPLES     FREQ       EXPECT
                                      0, 0   24,373,979    9.07%   Acceptable
                             0, 4294967294            2   <0.01%  Interesting
                    0, 9223372036854775806       38,613    0.01%   Acceptable
                    0, 9223372036854775807      726,094    0.27%   Acceptable
                    4294967294, 4294967294            2   <0.01%  Interesting
           4294967294, 9223372036854775806            1   <0.01%  Interesting
  9223372036854775806, 9223372036854775806       21,715   <0.01%   Acceptable
  9223372036854775806, 9223372036854775807      145,851    0.05%   Acceptable
  9223372036854775807, 9223372036854775807  243,455,002   90.58%   Acceptable

Also on Foojay This Month

Foojay Podcast #94: More Than a Blog

Foojay turned six this month, and Frank Delporte (Java Champion at Azul) marked it the way Frank tends to mark things - by heading to JCON Cologne with a microphone and not leaving until he had talked to twelve community members about what Foojay means to them. The result is the Foojay Podcast #94.

The thesis is right there in the title - “more than a blog” - and the episode lays out the case. Six years in, Foojay is also a Mastodon server, a Slack community, the Disco API behind SDKMAN and Gradle, a book on sustainability, this podcast, and (as of recently) an education catalog. The twelve guests are the receipts: Sharat Chander, MBA on 25 years of Java community history, Markus Westergren and Iryna Dohndorf on developer sustainability in the AI era, René Schwietzke on JIT and the 1B row challenge in pure safe Java, Gerrit Grunwald on the Disco API, Catherine Edelveis on container-size economics, ⚙️Jago de Vreede on a JavaFX UI for SDKMAN, Annelore Egger on mentoring future conference speakers, Buhake Sindi on Jakarta EE meets LangChain4J, François Martin on flaky tests, Dominika Tasarz (Frank’s new Foojay colleague) on what’s next - and Geertjan Wielenga , who started the whole thing six years ago, joining remotely from under a lighthouse in Ireland. A sentence I never expected to write. Solid hour, useful chapter timestamps if you want to skip around.

Which Java Runtime Should You Use in Production?

Catherine Edelveis (Developer Advocate at BellSoft ) wrote a comparison of eight major OpenJDK distributions - Temurin, Liberica, Zulu, Corretto, Semeru, Red Hat, SapMachine, Microsoft. She is up-front that she works for one of the vendors and Liberica gets a favorable description, but the framing of the article is genuinely useful: the binaries are essentially the same (all start from the same OpenJDK source), and what you are actually picking is support ownership and vendor accountability.

The interesting bits: SapMachine and Microsoft both occasionally include patches that have not been backported upstream - fine while you’re on those distributions, an interesting compatibility story the day you migrate off them. For teams without strong platform alignment (no AWS lock-in, no RHEL subscription, no SAP estate), Catherine lands on a clean framing: BellSoft and Azul stand apart because Java is their actual product, not one item in a broader portfolio. That shows up in support window length, legacy version coverage (both still offer commercial support for Java 6 and 7), and toolchain depth. Pair this with the Docker Official Images piece below.

The Road to Docker Official Images for Java: The Azul Zulu Story

After more than two years of back-and-forth (the original PR was opened in January 2024, finally merged on March 17, 2026), Azul Zulu builds are now Docker Official Images. Frank Delporte walks through what it actually took to get there - and the process is the interesting part, not the brand.

What I’d flag: the separation between “vendor provides Dockerfile + validation” and “Docker builds the image on their infrastructure” is what makes the program trustworthy. Even Azul has to file a PR and wait for Docker’s review and rebuild process before anything lands on Docker Hub - they cannot ship images directly. The other commitment Azul had to make was supporting all Java versions, not just LTS - because many developers test against upcoming versions and prepare codebases before the next LTS lands. From now on you can FROM azul-zulu instead of FROM azul/zulu-openjdk. The pre-existing azul/zulu-openjdk images are scheduled for deprecation later in 2026, so factor that into your migration calendar.

Spring I/O 2026: Field Notes from Barcelona

Steve Poole summarized Spring I/O 2026 in one sentence: “It was a Spring AI conference with a Spring Boot conference attached.” About one in three main-stage sessions over the two-day programme covered Spring AI, the MCP protocol, agents, or LLM-based application development. Josh Long opened Day 2 with Bootiful Spring Boot 4. By midday the auditorium had moved on to The Spring AI Ecosystem in 2026: From Foundations to Agents.

The data point Steve flags that I keep thinking about: Rod Johnson - Spring’s original creator - is currently touring with the same talk in two cities in one week, Building Killer AI Agents on Your Spring Stack with Embabel. When someone with that legacy in the Java world picks one topic and runs with it, the choice of topic is itself the headline. Spring is not just a web framework anymore; it is positioning itself as an agent platform, and that transition is going to keep getting louder through the rest of 2026. The classic Java-platform talks still happened - just in side rooms, with smaller crowds, after the main programme ended.

Building a Personalized Content Delivery System

Farhan Hasin Chowdhury wrote a thorough walkthrough of building a hybrid recommendation engine with Spring Boot 3.x, Spring Data MongoDB, and Spring AI on Java 21. There’s a companion repo, so it works as a tutorial - but the architectural decisions are the part worth attention.

Two scoring layers: content-based scoring using Map<String, Double> user preferences and a MongoDB aggregation pipeline ($objectToArray + $setIntersection + $reduce to compute the score server-side), and embedding-based similarity using Spring AI + Atlas Vector Search to catch matches the literal-tag layer misses (a game tagged “exploration” can surface for a user who specified “adventure”). Both scores normalize to 0-1 and combine with a weighted formula (default 0.6 content + 0.4 similarity). User ratings close the feedback loop with an exponential moving average that keeps weights bounded between 0 and 1 by construction. The article is also a useful reality check on what Spring AI actually does in this kind of system: most of the work is plain MongoDB aggregation, and Spring AI’s role is the embedding API. That is a sane shape for production.

Introducing Floci: A High-Performance, GraalVM-Powered AWS Emulator

Hector Ventura introduced Floci, a LocalStack-style AWS emulator built with Quarkus + Vert.x and compiled to a native binary with GraalVM. The numbers: ~24ms startup, ~13 MiB idle memory, ~90 MB image size, 25+ AWS services emulated (S3 with Object Lock, DynamoDB with Streams, SQS Standard/FIFO, Lambda, Step Functions, EventBridge, Cognito, IAM, KMS, more), passing 400+ AWS SDK compatibility tests. MIT-licensed, no auth, no API keys, no telemetry, no accounts.

docker run -p 4566:4566 hectorvent/floci and you’re going. If you’ve been spinning up Testcontainers around LocalStack and feeling the warmup tax getting silly, this is a serious alternative to bookmark. Also a nice case study for the broader “GraalVM native is a serious infrastructure choice” argument - the fact that a individual-led open-source project can hit a 24ms cold start with a 13 MiB resident set is the kind of number that simply did not exist for JVM tooling five years ago.

Repo: github.com/hectorvent/floci.

And that’s all, folks.

And the resulting pile is unusually rich in stories: people, governance moves, ecosystem direction, and a few projects that are quietly redrawing the JVM map. Let’s go.

1. April: The Rest of the Story

You might remember from last month’s ROTS that I covered Jonathan Vogel “Java Is Fast. Your Code Might Not Be” - the DevNexus-talk-turned-blog-post about how application-level inefficiencies bottleneck even the fastest runtime. I closed that section with “Thanks Jonathan, can’t wait for the followup articles!” Well - Part 2 dropped in April, and it’s exactly what you’d want from a follow-up. Where Part 1 was the catalogue of anti-patterns, Part 2 is the actual investigation: open the JFR recording in JMC, look at the flame graph, watch one method consume 71% of CPU samples, fix it - and then watch what was previously buried in the noise become visible.

If you read Part 1 and went “yeah but where do I actually start”, Part 2 is that walkthrough. Demo app on GitHub with main (anti-patterns intact) and performance-optimized (fixed) branches - diff them yourself. Part 3 is promised to look at automating the loop with tools that read JFR, rank anti-patterns by hot-path weight, write the code changes, and hand you a diff. I’m... cautiously optimistic about that one. We’ll see.

JetBrains announced on April that Junie CLI - their coding agent introduced back in January 2025 - can now detect any JetBrains IDE running on your workstation and connect to it automatically. On the surface this sounds like a small UX improvement. It is not. This is the most strategically important thing JetBrains has shipped in the agent space this year, and it’s the move that finally makes the “Junie + Air + Central + ACP Registry” story (which we walked through in vol. 168) feel coherent.

Two caveats. First, this is beta and a subscription service - the whole Junie offering is paywalled, this isn’t a free-tier expansion. Second, Android Studio support is “planned”, which means anyone doing serious KMP work today still has to make do with the IntelliJ side of the bridge.

But strategically: if JetBrains keeps this working reliably across their IDE family, “agent that thinks at the same level as my refactor tool” becomes a value proposition a generic CLI cannot match. This is the piece I expect to actually move enterprise adoption needles over the next two quarters.

The end of an era: Project Metropolis goes to a CFV. This one made me a bit melancholic. Vladimir Kozlov initiated a Call For Votes on April 21 to withdraw HotSpot Group sponsorship from the OpenJDK Graal and Metropolis projects - operating under Lazy Consensus rules, voting period ending May 4. Effectively: dissolution.

If you weren’t around for it, Project Metropolis was - and I cannot overstate this - one of the most ambitious experimental tracks in OpenJDK’s history. The premise: rewrite significant parts of HotSpot’s C++ runtime in Java itself. “Java-on-Java.” Replace C2 with a self-hosted JIT compiler written in Java, statically compiled via Substrate VM. The vision was a JVM that bootstrapped itself out of its own legacy C++ codebase, using its own type system to catch its own bugs, with all the maintainability gains that implied. It was the kind of swing-for-the-fences proposal that only a community of people who genuinely believe in their tools makes.

What happened? GraalVM happened. Specifically, GraalVM thrived as an external runtime - and last September’s decision to formally decouple GraalVM from the core Java release cycle made it clear that the strategic future for Graal-as-product was as a separate, vendor-led distribution rather than as the JIT inside mainline OpenJDK. Once that direction was set, the internal Metropolis project - whose entire reason for existing was integrating Graal as the HotSpot JIT - became orphaned by its own success on the outside. The Java-on-Java vision didn’t fail technically. It got out-strategized by ecosystem reality.

For JVM veterans, this is “end of an era” stuff. HotSpot’s C++ foundations are now officially the long-term future. There won’t be a self-hosted mainline JIT, at least not via this initiative. If you ever sat through one of John Rose’s talks about the implications of compiling the JVM in itself - yeah, that future is shelved.

GraalVM itself, of course, continues. It’s still an excellent runtime, still the basis for Native Image, still where most of the actual Graal innovation happens. But the ambition of folding it into the JDK proper is being formally retired. It’s a quiet end to a technically daring experiment, and worth marking the moment.

Apparently February’s “Koog for Java” reveal at JavaOne wasn’t going to be the end of it. JetBrains announced direct integration between Koog - their JVM-native AI agent orchestration runtime - and the Spring AI ecosystem.

The pitch is sensible: Spring AI handles the what (model communication, abstractions, vector stores, beans), Koog handles the how (agent state, history, flow, lifecycle). Koog acts as an “orchestration skin” - you keep using your Spring AI providers and vector stores, but the agent logic lives in Koog’s directed-graph workflow model. The properly interesting piece is what Koog manages on the lifecycle side: native crash recovery preserves execution state across restarts, and automated history compression mitigates LLM context window constraints transparently.

If you’ve built an agentic system in production, you know that “what happens when the JVM bounces mid-conversation” is one of those questions that has no good answer in vanilla LangChain4j or Spring AI alone. You either roll your own checkpointing (good luck) or accept that long-running agents will lose state on restart (also bad). Koog solving this at the framework level - and now plumbing into Spring AI cleanly - is genuinely useful.

Spring patches three CVEs in one go - plus a Spring Cloud Gateway one Quick public-service announcement, because four CVEs in two weeks deserves a flag.

Spring Framework 7.0.7 and 6.2.18 shipped April 17 and patch three CVEs:

• CVE-2026-22740 - DoS via multipart temp files in WebFlux. Temp files from multipart requests can fail to be deleted, exhausting disk space.

• CVE-2026-22741 - Static resource cache poisoning in Spring MVC and WebFlux. Specially-crafted requests can poison the cache with wrongly-encoded resources, breaking the front-end for everyone else.

• CVE-2026-22745 - DoS in static resource handling on Windows specifically. Slow-resolving requests can keep HTTP connections open indefinitely.

A week earlier, Spring Cloud Gateway 4.2.0 hit with CVE-2026-22750 - and this one is a particularly sneaky failure mode. The spring.ssl.bundle configuration property was being silently ignored, defaulting to the default SSL configuration with no log message and no warning. If you set this property believing it was applying a custom bundle, you weren’t getting that bundle and you had no way to know. The “false sense of security” framing in Spring’s writeup is unusually honest and accurate.

None of these are RCE-class, but the cache-poisoning one has clean exploitation paths and the SSL-bundle bypass is exactly the kind of silent misconfiguration that survives in production for ages. If you’re on Spring 7.0.x or 6.2.x: patch. If you’re on Spring Cloud Gateway 4.2.0: patch. If you’re still on Spring 5.x: I’m sorry about your maintenance backlog, and you have bigger problems anyway.

Ivar Grimstad weekly Hashtag Jakarta EE updates remain the most reliable signal on Jakarta EE 12 timing, and the April 19 edition gave us the cleanest milestone schedule we’ve seen so far. The Platform Project has now committed to:

• M4 (Apr 1 – May 15, 2026) - Core Profile specs to show progress: REST 5.0-M1, CDI 5.0 milestone/beta (currently at Alpha4), JSON-P 2.2-M1, JSON-B 3.1-M1

• M7 (Aug 15 – Sep 30) - Ideally Core Profile released

• M9 (Jan – Feb 2027) - Finalize remaining specs

• M10 (Feb – Mar 2027) - Platform TCK with ratifying implementation

So the realistic read: Core Profile in Q4 2026, Web Profile and full Platform in Q1–Q2 2027. Same shape as Jakarta EE 11, which is at least predictable.

The active debate worth flagging: whether Jakarta NoSQL gets included in EE 12 at all. Grimstad noted explicit resistance among some members, and called for community voices on either side. If you’ve been using Eclipse JNoSQL in production and want it standardized, this is your window - speak up on the Jakarta EE Platform mailing list before the inclusion decision sticks.

Other specs targeting M2 release: Jakarta Connectors 3.0, Faces 5.0, Transactions 2.1, JSON-P 2.2.

Continuing the JetBrains-makes-everything-an-agent theme: a specialized AI agent skill landed in the kotlin-agent-skills repository targeting Kotlin Multiplatform → Android Gradle Plugin 9.0 migrations. AGP 9.0 demands JDK 21 and Gradle 8.10.2, and the migration involves breaking changes to the build DSL plus the complete removal of the legacy PackagingOptions. Anyone who’s done this manually on a non-trivial KMP project knows the pain.

Couple of observations. First: this is the kind of “agentic skill” that LLMs are actually good at - narrowly-scoped, mechanical, structurally well-defined transformations on a constrained input grammar (Gradle DSL). It’s the agentic-coding sweet spot, and probably more reliably useful than the “vibe-code me a feature” style. Second: the necessity of such tools underscores how deep the Android-Kotlin build stack complexity has gotten. The fact that a major version bump now warrants its own purpose-built migration agent says something - and not entirely a flattering something - about where Gradle DSL ergonomics have ended up.

Either way: if you’re staring down an AGP 9.0 migration on a multi-module KMP codebase, this is worth a look before you do it by hand.

2. Release Radar

TornadoVM 4.0.0 GA

We already mentioned it, but treat tis as a necessary due diligence.

The main feature of TornadoVM 4.0 is genuinely big: a new hardware backend supporting Apple Silicon via the Apple Metal API. After years of Apple Silicon being a second-class citizen for serious GPU compute on the JVM, TornadoVM 4.0 now has a native path. Combined with the OpenCL, PTX, and SPIR-V backends, you can now legitimately develop and prototype heterogeneous Java workloads on a MacBook before deploying to NVIDIA, Intel, or AMD hardware. For anyone working on GPULlama3.java-style projects or AI inference in pure Java, this is the release that makes Mac local development viable.

Helidon 4.4.0

Helidon 4.4.0 (released around JavaOne) is a substantial release: agentic LangChain4j patterns, Helidon JSON (compile-time JSON, incubating), expanded declarative APIs (WebClient, WebSocket, Health Checks, Telemetry, Metrics, CORS, Security), unified OpenTelemetry story including OTLP-exported metrics and configurable OpenTelemetry logging, plus formal entry into Oracle’s Java Verified Portfolio. Notable deprecations: the Jaeger tracing provider is deprecated (OpenTelemetry’s Jaeger exporter is gone), and CORS configuration moved from feature-specific to centralized top-level. Then 4.4.1 followed quickly with bug fixes (gRPC server-side error handling, Prometheus metrics performance, Netty 4.1.130.Final, Apache commons-text 1.15.0). Upgrade path is clean - review the deprecations section, then jump.Release notes.

Hibernate ORM 7.3.0

The headline of the new Hibernate 7.3.0 is improved natural ID support. New KeyType enumeration lets the overloaded find() and findMultiple() methods do natural-ID-based loading, and new @NaturalIdClass annotation mirrors @IdClass semantics for non-aggregated composite natural IDs. If you’ve wrestled with composite business keys (and who hasn’t), this finally aligns the natural-ID path with the JPA-standard identifier path.

LangChain4j 1.13.0

In LangChain4j .1.13.0 new RecoverabilityIT and PendingResponse classes make agentic execution state persistable and recoverable across restarts - solving the same problem Koog tackles from the JetBrains side, and confirming that resilient stateful agents are now a baseline expectation across the JVM AI stack.

Also: a new ClassPathSkillLoader (Anthropic-style “Skills” come to LangChain4j) and a new HibernateContentRetriever running HQL queries as a retrieval source - the Hibernate-as-knowledge-graph pattern Belladelli demoed at JCON Europe (see §1) made flesh in code.

Keycloak 26.6.0

Full RFC 7523 support (JWT profile for OAuth 2.0 client auth/authz grants), experimental support for the OAuth Client ID Metadata Document draft - relevant for serving as an authorization server for the latest MCP spec - and full support for the new Keycloak Test Framework on JUnit 6. The MCP-as-OAuth-resource-server piece is genuinely useful if you’re building agent infrastructure that needs proper auth instead of API-key duct tape. Release notes.

Apache Camel 4.19.0

Possibly the most feature-rich release on this list. New components: Azure Functions, Groovy JSON dataformat, and - interestingly - Spring AI Image, bringing Spring AI’s image generation flow into Camel routes. The PQC component now supports hybrid post-quantum cryptography, key lifecycle management, and platform-wide quantum-safe TLS readiness - which sounds aspirational but aligns with where JEP 527 is going on the JDK side. Plus support for Spring Boot 4.0.

Open Liberty 26.0.0.4 beta

JDK 26 support, new features for Jakarta EE 11 Platform (jakartaee-11.0) and Web Profile (webProfile-11.0), Authentication 3.1, Authorization 3.0, Security 6.0 (Jakarta Security 4.0). The mcpServer-1.0 feature now allows dynamic tool registration, which is the practical thing you need if you want to use MCP for anything beyond a static demo. Combined with last month’s MCP additions, Open Liberty continues being one of the first enterprise Java application servers to take MCP seriously.

CheerpJ 4.3

Leaning Tech shipped CheerpJ 4.3 - the WebAssembly-based JVM that runs unmodified Java applications in the browser. The 4.3 release continues the steady iteration toward “yes, you can actually run this Swing app in your browser tab without installing anything.” For preservation work, edu-tech, and certain very specific enterprise reanimation cases, this remains a remarkable piece of engineering. The r/java thread had the usual mix of amazement and “but why” - both reasonable reactions.

Native Image Config Transformer 1.0.1

Michael Simons released v1.0.1 of his native-image-config-transformer - a Maven Shade Plugin extension that bridges JAR shading and GraalVM’s static analysis requirements. If you’ve ever produced a fat JAR with Shade and then watched GraalVM’s reachability metadata go stale because the plugin renamed your packages but not the metadata files, this fixes that. v1.0.1 adds support for the reachability-metadata-schema-v1.2.0.json format. Niche, high-utility, exactly the kind of “small tool that quietly fixes a real-world pain point” the GraalVM ecosystem benefits from.

Amper 0.10.0

For those keeping track of the JetBrains-tries-to-fix-build-tooling saga: Amper continues iterating on its declarative-YAML-but-not-really build configuration model. Worth watching if you’re tired of Gradle Kotlin DSL complexity, but I’d still call this “interesting experiment, not yet a Gradle replacement for serious projects.”

JBang 0.138.0

JBang now executes WAR files with the same handling as JAR files. Small change, useful if you carry a WAR around for legacy testing reasons. The deprecated isJar() method on Project is preserved for backward compat.

3. GitHub All-Stars

A handful of community projects worth flagging this month - none release-worthy in the formal sense, but interesting enough that I’d hate to lose them in the noise.

Server-Components - Phoenix LiveView, on the JVM

Server-components by vadimv brings the Elixir Phoenix LiveView model to the JVM. Stateful, server-driven rendering over WebSockets, no SPA stack required. The project’s architectural philosophy is the interesting bit: it deliberately rejects “magic” - strict avoidance of annotations and implicit execution flows, in favor of explicit control. Roughly 12,000 lines of modern Java, vertically integrated, near-zero runtime dependencies. The author explicitly cites AI-agent-friendliness as a design constraint - predictable, readable code structures are easier for both humans and LLMs to navigate.

I’m genuinely interested in this one. The “JS-less interactive UI” argument has resurfaced via HTMX, Hotwire, and now LiveView ports - and the JVM has been weirdly underrepresented in this conversation. Worth keeping an eye on.

AlgoFlow - bytecode-instrumentation-based algorithm visualizer

AlgoFlow takes a different route to algorithm visualization: a Java Agent that injects visualization callbacks directly into JVM instructions, capturing state changes (array assignments with computed indices, etc.) without source-level integration. This is genuinely clever - the vast majority of educational visualization tools require either heavy code annotation or a step debugger, and AlgoFlow side-steps both via bytecode instrumentation.

The r/java response was polarized - the Java backend got praise, the AI-generated frontend less so. That’s a shame, because the core technique is the interesting bit. If the developer trades in the AI-generated UI for something more polished, this could be a real teaching tool. Watch this space.

WebAssembly4J 1.0.0 - unified Wasm API for the JVM

WebAssembly4J provides a unified API across multiple Wasm runtimes (Wasmtime, WAMR, Chicory) with dual integration paths: JNI for Java 8/11 compatibility and Project Panama (FFM API) for Java 22+. Continues the trend we covered with swc4j in vol. 168 - the “black box script engine” era is giving way to more transparent, low-latency execution models where Wasm becomes a first-class JVM citizen. If you’re building plugins, sandboxes, or polyglot integration, the Wasm-on-JVM space is suddenly worth following again.

MelodyMatrix 1.0.0 - JavaFX + jdeploy as a delivery model

MelodyMatrix by Frank Delporte isn’t important for what it does (it’s a music-related tool) - it’s important as a case study for how to ship a JavaFX desktop app in 2026. The release walkthrough on Foojay covers the full pipeline: jdeploy for cross-platform native installers, GitHub Actions for the build, auto-update integration, the works.

JavaFX in 2026 is in a much better shape than the discourse credits it for, and projects like this one are why. If you’ve been holding off on a desktop Java tool because “distribution is a nightmare,” read this.

Shroom - “if jvm and c had a baby”

A small Polish-fronted curiosity that I genuinely enjoyed: shroom by Wiktor Kęska a tiny C-like language that compiles to JVM bytecode and uses Panama (Foreign Function & Memory API) for manual memory management. You write code with pointers, malloc/free, and structs; the compiler turns it into .class files; under the hood, every pointer is a MemorySegment, every malloc is Arena.allocate(), and every dereference is segment.get()/segment.set(). The toolchain is the cool bit - ANTLR for parsing, walks an AST, then ASM to emit bytecode, then Panama Linker for native FFI when you want to call into libc.

What sells it for me is that it’s a complete loop: source goes in, real .class files come out, and Kotlin/Java/Scala can call them via plain invokestatic - Sieve.countPrimes(1_000_000) compiles to a regular static method call. The arena modifiers (confined, shared, global, auto) are a particularly nice touch - you control memory lifetime per function, and the arena gets closed (freeing all mallocs in one go) when the function returns. It’s a great teaching artifact for anyone who wanted to understand how Panama, ANTLR, and ASM actually fit together.

And from the license section: “Experimental. No license. Don’t use in production. If it breaks, you get to keep both pieces.” Exactly the right energy.

Requires JDK 22+ (since Panama is finalized there). Star it for the educational value alone - this is the kind of repo I’ll be sending people who want to actually grok how the pieces of the modern JVM puzzle slot together.

Controller-Client - Spring Boot tests without the MockMvc boilerplate

From the same author as shroom: controller-client is a much more practical offering - a Spring Boot testing library that wraps MockMvc with dynamic proxies so you can call your controller methods directly in tests, type-safe, no JSON-string-massaging required. Instead of the usual ceremony:

String responseContent = mockMvc.perform(get("/example"))
    .andExpect(status().isOk())
    .andReturn()
    .getResponse()
    .getContentAsString();
ExampleResponse response = objectMapper.readValue(responseContent, ExampleResponse.class);

you get

@AutowireControllerClient
private ExampleController exampleController;

@Test
void basicGet() {
    var response = exampleController.exampleMethod();
    assertThat(response.message()).isEqualTo("Hello world!");
}

That’s the whole pitch, and honestly it’s enough - anyone who’s written ten MockMvc tests has felt the boilerplate fatigue. The library is at v2.3.0 (December 2025), Spring Web only, and per the README “still in early stage, so it doesn’t support all spring web annotations” - but the core pattern is right and the customizer hook (ControllerClientAnnotationCustomizer, e.g. for adding CSRF tokens to every request) is extensible enough to cover the common needs.

Available on Maven Central as io.github.1grzyb1:controller-client:2.3.0. Worth a look if you’re tired of writing objectMapper.readValue(...) for the hundredth time.

PS: KotlinConf 2026 is around the corner - reminder that I’ll be there as media partner. Come say hi.

PS2: Heads-up that next month is going to be heavy on retro, because both the Vibe Engineering MEAP is hitting milestones and there’s a NYC Tech Week event in early June tied to the book. Expect some self-promotion. I’ll keep it short.

KotlinConf 2026 is right around the corner - May 20–22, Munich, ICM Messe. JVM Weekly once again has the pleasure of being a media partner for the event, and on that occasion I decided to do something I don’t usually do in this newsletter: write about my own project.

A year ago I had the chance to stand on stage in Copenhagen with a talk called “Build your own NES Emulator... with Kotlin“. kNES - my Kotlin NES emulator - had been living quietly on GitHub ever since.

Then it stopped being quiet. Because doing stuff these days is… easier. First I wanted to play with JoyCons instead of a keyboard, then I wanted to expose a REST API, then add MCP, and then Claude picked up the controller and started playing Final Fantasy 1. Each new layer was a single evening of work - because one small interface turned out to be enough for all of them.

Not even starting about having fun with NES in terminal.

With KotlinConf approaching, I figured it’s time to share what happened over the past year - especially since I’ve had some rather interesting journey 😁

I’m not speaking this year on conference, but I’m going to attend as JVM Weekly once again has opportunity to be a media partner of the event, so at the end - so at the end - five talks from this year’s agenda that I personally plan to attend.

A Year After KotlinConf: How JoyCons in a Hotel Room Started an Avalanche

For those who didn’t see the talk: kNES is a NES emulator written in pure Kotlin - 6502 CPU, PPU, controllers, frame timing. Compose Desktop as the UI (probably worst UI you have ever seen, shame on my but it was never that important in that project), multi-module Gradle, zero native dependencies. A side-project that started during the pandemic as an exercise in low-level Kotlin and sealed classes, and at KotlinConf 2025 ended with a live demo of Super Mario Bros on stage.

After the conference, one question stuck with me - one I didn’t have time to properly answer from the stage: “OK, cool side-project, but what’s next?”

The answer started a few months later, at Kotlin Dev Days. Hotel room, evening, beer, an idea: “I’ll add JoyCon support.” JInput, polling on a separate thread, mapping axes and buttons - the usual. But to add gamepad support without gutting the entire CPU and PPU, I first had to refactor how the NES receives input. In the original version, KeyListener was hardwired into the emulator core through globals. To add a gamepad, I extracted it behind an interface:

interface ControllerProvider {
    fun getKeyState(padKey: Int): Int  // 0x40 = released, 0x41 = pressed
}

Two implementations - KeyboardController and GamepadController - one evening’s work, done.

And that’s where I should have closed the laptop. I didn’t. I was hooked and I wanted to push this thing to the absolute maximum. If ControllerProvider handles a keyboard and a gamepad, then why not HTTP? Why not MCP? Why not an autonomous agent? The 6502 CPU only knows one thing: “ask my ControllerProvider what’s happening with button number X.” It doesn’t care whether there’s a keyboard on the other end, a JoyCon over Bluetooth, a POST from curl, or an LLM talking to a server on stdio.

ApiController - the third implementation - took me two evenings. Ktor on port 6502 (naturally). The fourth layer, the MCP server, was a thin proxy over the same REST API. And just like that, the emulator that a year ago ran Super Mario from a keyboard got a new player - Claude Code (because it’s wonderful agents prototyping tool.

It sat down, loaded the Final Fantasy 1 ROM (dumped personally for that purpose, of course), created a party (Fighter / Thief / Black Belt / Red Mage, a classic), walked out of Cornelia Castle, fought five IMPs on the overworld, and wrote in my log

VICTORY! All characters gained 7 XP. Gold went from 400 to 430. THIEF took the most damage (down to 12 HP) and the Red Mage dodged everything (still full at 30/30). That was a tough fight for level 1!

I could have said “neat side-project” and moved on. But the road from JoyCons to that VICTORY! turned out to be a surprisingly good testing ground for three things we usually write about separately: Kotlin in low-level contexts, designing APIs for LLMs, and how small interfaces scale in directions nobody imagined when writing them.

Below - a catalogue of challenges. The kind where if you ever want to build a similar setup, you’ll know where it’s going to hurt.

1. An LLM Can’t See Pixels - It Needs to See RAM

The first instinct is: “give it a screenshot.” 256×240 NES pixels → PNG → base64 → tens of kilobytes per tool call. The problem: Claude does see the image, but the interpretation is slow, expensive, and unreliable. Retro graphics means 8×8 fonts, single-pixel menu cursors, dithered sprites. Vision models simply don’t handle this well.

How badly? The first FF1 session looked like this: Claude spent fifteen minutes walking in circles on the title screen, describing “I see a blue screen with white text, possibly the title screen” and being completely unable to extract anything useful from the image to make a decision.

The solution came from the same place speedrunners and TAS tool-assisters have been getting theirs for two decades - the game’s RAM. Final Fantasy 1 stores screenState at $0075, character HP in sequential bytes, battleTurn, enemyCount, worldX, worldY at known addresses. That’s the truth of the game, not its visual representation.

In the knes-debug module I built GameProfile - static registries with a list of watched RAM addresses per game. For FF1, that’s ~40 watches established from disassembly and the Data Crystal database. The MCP get_state tool returns a dictionary {name: value} - and suddenly Claude understands the game:

BATTLE! We’re fighting IMPs! I can see: 5 IMPs (enemy1 HP: 8, enemy2 HP: 8, enemyCount: 5). Our party: all 4 characters with full HP. screenState = 104 (battle), battleTurn = 2. Let me wait for battleTurn = 0x55 (player input time), then have all 4 characters FIGHT.

[SCREENSHOT: Claude Code - same game, but with RAM watches. Claude describes the tactical situation based on get_state, citing specific addresses and values. The comparison with the previous screenshot speaks for itself]

A qualitative shift. Claude doesn’t “look at the screen” - it reads RAM. Exactly what TAS-ers have been doing for years. The screenshot stays as a fallback for debugging by the human operator, but it’s no longer the primary source of information.

Lesson for anyone building anything for an LLM: map your domain to JSON. Don’t count on the vision model “seeing the table.” A symbolic representation of state is almost always better than an image - even if it means manually mapping addresses from disassembly.

2. Round-Trips Kill the Gameplay

OK, so Claude reads RAM and understands what’s happening. But it plays slowly. Very slowly. Really very slowly.

The first version of the MCP server had one tool - step(buttons, frames). Press A for 5 frames, seems reasonable. But do the math. One A press in battle takes three tool calls: press, release and wait, check state. Each one is a round-trip through MCP + a round-trip to the model + ~1–3 seconds of thinking time. One A press: five seconds. A battle with five IMPs, where each round is four characters × two presses × several rounds: 60+ tool calls. Five minutes of wall-clock time for a single fight. Castle exploration: 200 tool calls. The full game: tens of thousands. Infeasible.

Claude noticed this himself - a quote from the logs, worth reading carefully:

I realize I’m stuck on the 2nd floor of Cornelia Castle - navigating this castle one tile at a time with only the step tool is incredibly slow. [...] The tap tool alone would save enormous time - right now pressing A 5 times requires 10 tool calls (press + release gap each), while tap(”A”, count: 5) would be just 1 call.

(Yes, Claude complained about my API. He was right.)

The fix - three batched tools that Claude essentially co-designed with me during that same session. step got a screenshot flag so you don’t need a separate call for the screen capture. A new tap tool lets you say “press A five times with 30-frame gaps” in one call instead of ten. And finally sequence - an atomic list of steps, an entire corridor exploration as a single request with 30+ {buttons, frames} pairs.

Result: the IMP battle dropped from five minutes to ~40 seconds. Cornelia Castle became traversable. The game went from impossible to slow - but playable.

Lesson: when designing an MCP API, count how many tool calls a realistic workflow takes. If it’s more than twenty - you need a batched variant. The cost of a round-trip isn’t just network latency - it’s the cost of a decision. Every tool call is a separate inference step. An API for an agent is 80% a step-compression problem - and that’s a fundamentally different challenge than designing a REST API for a human.

3. Race Conditions at 60 FPS

This is where things got really interesting from a JVM perspective.

The Compose UI drives the NES on its own thread - 60 frames per second, ~29,780 CPU cycles per frame. The Ktor API lives in a separate coroutine pool. When Claude sends step(buttons=[”A”], frames=1), the Ktor thread sets the button state and waits for the frame to end. Simple? No. Every third or fourth call was getting lost.

I add logging. It turns out Claude was right when he said A “didn’t work”: in a step with frames=1, the press would vanish before the NES CPU had time to poll the joypad. The FF1 game code reads port $4016 at a specific point during vblank - if setButtons() arrived a millisecond too early or too late, the input evaporated into nothing.

Naive fix: @Volatile on the state array. Helps with cross-thread visibility, doesn’t help with timing. Input can still arrive mid-frame and disappear before the poll.

The fix that actually worked: FrameInputQueue - a queue synchronized with the PPU frame boundary. The Ktor thread calls enqueue() and blocks on a CountDownLatch. The imageReady callback (fired at each frame boundary) pops the next state and counts down the latch. Short presses last exactly one frame and don’t vanish. The API thread blocks deterministically until the end of the requested sequence. Zero mutexes - @Volatile, ConcurrentLinkedQueue, CountDownLatch. Three classes from java.util.concurrent and the problem is solved.

Lesson: concurrency in retro emulation is hardware ticking at a specific frequency that couldn’t care less about your Ktor thread. The JVM gives you exactly the tools to build the bridge, but you need to know what you’re synchronizing. In this case: the PPU frame boundary. Not “access to a variable,” not “a critical section” - the physical moment when the virtual cathode ray finishes drawing the image.

4. “looks like cheating but you can try :D”

With the timing fixed and the batched tools in place, Claude was playing. Slowly, but playing - and that’s when the most interesting design moment of the whole project happened.

During the IMP grinding, Claude suggested:

I typed, half-joking: “looks like cheating.”

Claude, after a brief pause: “looks like cheating but you can try :D” - and immediately started exploring how to implement it.

I stopped him with one serious sentence: “Yes, but one rule - don’t do anything that is not allowed on real NES.”

That constraint - imposed via a single line in a chat - became the foundation of all subsequent architecture. The agent can read RAM (the equivalent of looking at the screen), press buttons (A, B, START, SELECT, D-pad), and wait. That’s it. No memory writes, no save states, no RNG manipulation. No enemy_hp = 0.

From that rule emerged a pluggable GameAction system - an interface through which you can write bots for any NES game, with their maximum power bounded by the physics of a real controller:

interface ActionController {
    fun readRam(addr: Int): Int
    fun pressButton(key: Int, pressFrames: Int, gapFrames: Int)
    fun waitFrames(n: Int)
    // nothing else. No writeRam. No saveState.
}

The first implementation - BattleFightAll for FF1 - reads screenState, waits for battleTurn to indicate player input time, presses A twice per character (FIGHT + default target), waits for the round animation, repeats. It’s not a cheat. It has no access to anything a human player with a thumb on A wouldn’t have. The only “advantage” - zero reaction time. It plays ~3× faster than I do with a gamepad, but under exactly the same rules.

And here’s the moral I’ve been building toward from the start: constraining an agent to “what a human can do” is not a moral flag. It’s a design tool. Without that constraint, I’d have ended up with a function that writes to memory and returns. Instead, I have a framework with clean architecture that can be extended to other games. Design constraints pay dividends in elegance - and that’s probably the most important lesson from a year of working on kNES.

What You Take Away If You’re Not Writing an Emulator

Most JVM Weekly readers won’t be writing NES emulators (heh, at least I assume so). But four things from this project transfer 1:1 to any JVM app integration with an LLM.

First - small interfaces are an investment. ControllerProvider was born in a hotel room at Kotlin Dev Days because I wanted to play with JoyCons instead of a keyboard. A few weeks later it turned out to be a universal entry point for HTTP, MCP, and an autonomous agent - without touching a single line in the 6502 CPU. Interfaces pay off not when you add the second implementation, but when the third one grows out of a use case that didn’t exist when you wrote the code.

Second - symbolic state representation beats a screenshot. Map your domain to JSON. Don’t count on the vision model “seeing” what it needs to - even if that means hand-typing RAM addresses from a disassembly.

Third - batch your tool calls. Every round-trip is a separate inference step. step + get_state + get_screen → one step(screenshot: true). Simple refactor, 3× more throughput. If your agent needs more than 20 calls for a single task - you have an architectural problem, not a performance one.

Fourth - constraint is a gift. Imposing “the agent can only do what a human can” forced a better architecture than “let’s build a function that wins the fight.” Next time you’re tempted to give the agent a shortcut - consider whether a constraint might be the better choice.

Code: github.com/ArturSkowronski/kNES. This also powers geecon talk - I’m hoping to show it live, with Claude driving the emulator from the stage. You are all invited 😁

PS: Five KotlinConf 2026 Talks I’m Keeping an Eye On

Since we’re on the topic of KotlinConf - this year the conference moves to Munich (May 21–22, workshops on May 20) and the agenda is packed. 80+ talks, eight parallel tracks. I went through it pencil in hand (yes, I know - analog) and picked five sessions I personally plan to attend. This isn’t a ranking - more of a subjective list from someone who spent the last year thinking about Kotlin in unusual contexts.

Deconstructing OkHttp by Jesse Wilson

Jesse doesn’t show how to use OkHttp - he takes it apart. Interceptor architecture, connection lifecycle, caching state machines, performance optimizations. A masterclass in reading and learning from high-quality Kotlin code. Anyone who’s written anything low-level in this language (ahem, emulators) knows that a deep-dive into a well-designed library teaches more than five tutorials. Jesse has been a guarantee of presentation quality for years - this is a talk I’d go to even if I’d never touched OkHttp.

Talking to Terminals (And How They Talk Back) - Jake Wharton

How terminals actually communicate with applications - colors, sizing, frame sync, images, keyboard events - and how to handle it all in Kotlin, including JVM vs. Kotlin/Native differences. Sounds niche? Maybe. But this is exactly the type of talk after which you go back to your hotel and rewrite half your tooling.

As someone who rendered a NES in a terminal, I can confirm: low-level terminal APIs are a rabbit hole you don’t leave without a few scars. Jake is one of the few people I trust on this topic.

Full-Stack Kotlin AI: Koog + MCP - John O’Reilly

This talk is close to my heart for obvious reasons - MCP, AI agents, Kotlin, all in one. John shows how to use Koog (JetBrains’ agent framework) as the intelligent core of a Compose Multiplatform app, connecting to an MCP server through the Kotlin MCP SDK with both cloud and on-device LLM integration. Anyone who read the sections above about my battles with tool calls knows this isn’t an academic topic. I’m genuinely curious whether John hit the same round-trip pitfalls I did - and how he solved them.

How google.com/search builds on Kotlin coroutines for highly scalable, streaming, concurrent servers - Sam Berlin & Alessio Della Motta

Google Search running on Kotlin coroutines. Qflow, latency instrumentation, critical path analysis in “asynchronous by default” systems. I was wrestling with synchronizing one emulator thread with one Ktor thread. These folks synchronize billions of requests. The perspective is slightly different (heh), but the fundamentals - Kotlin, coroutines, java.util.concurrent - are the same. This is the kind of talk where the sheer scale of the system forces solutions you wouldn’t normally even think about, and you leave the room with a head full of ideas.

Go Get It, with Kotlin: Evolving Uber’s Java Backend - Ryan U.

Uber introduced Kotlin into their massive Java monorepo. Building the business case, patching tooling gaps, overcoming skepticism, enabling adoption for thousands of engineers. After last year’s talk by Ty Smith on migrating millions of lines of Java to Kotlin - which was my favorite from KotlinConf 2025 - this one looks like a natural continuation of the theme. Large-scale migration is the kind of problem that looks simple from a distance and turns into a labyrinth up close. I’m expecting solid engineering substance.

Full KotlinConf 2026 agenda: kotlinconf.com/schedule. See you in Munich!

PS: This is the last opportunity to buy tickets - Last Call 🤫. Just Saying

Just a month after JDK 26 shipped, the release machine is already running at full speed. Mark Reinhold has formally proposed the release schedule for JDK 27, early-access builds are already in double digits, and on top of that, the JVM community is buzzing with discussion around OpenJDK’s new policy on generative AI. A lot is happening - let’s break it down.

1. JDK 27: The Calendar and the Only (So Far) Official JEP

Mark Reinhold, Chief Architect of the Java Platform Group at Oracle, formally proposed the release schedule for JDK 27: Rampdown Phase One (fork from main line) is set for June 4, 2026, with GA - as tradition dictates - in September. The review period for this schedule concluded on April 13, so we can effectively treat these dates as locked in. Build 17 early-access is already publicly available.

This means JDK developers have less than two months to target additional JEPs. And right now, we formally have one single officially targeted JEP: JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3. It enhances TLS 1.3 with a hybrid key exchange mechanism resistant to quantum computing attacks, building on JEP 496 (Quantum-Resistant ML-KEM) delivered in JDK 24. The topic of “quantum-ready” cryptography is slowly shifting from the “science fiction” category to “infrastructure we should have had yesterday” - especially if you operate in regulated sectors. The first JEP targeted to the twenty-seventh version of Java is about security - and that says something about priorities.

But “one official JEP” doesn’t mean it’s going to be boring. Based on JEPs in Candidate status and active drafts, we can point with reasonable confidence to what else should land in JDK 27 - and this is where things get interesting.

2. Valhalla Finally Knocks on the Door: JEP 401 Value Classes

If I had to bet on which JEP will be the most important one in JDK 27, I’d go all in on JEP 401: Value Classes and Objects (Preview). Project Valhalla, after years of conceptual work and prototyping, has a real chance of debuting in preview in the mainline JDK.

What’s the deal? Value classes are classes whose instances lack object identity. == compares them by field values, not by reference. Sounds simple, but the implications are massive - the JVM can optimize their memory layout through heap flattening (objects in arrays stored flat, without indirection) and scalarization (avoiding allocation in JIT-compiled code). And the code change? Laughably small:

// One keyword changes everything
public value class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

// Works with records too:
public value record Color(byte r, byte g, byte b) {}

The value keyword before class or record - and instances lose their object identity. All fields are implicitly final, the class is implicitly final, and the JVM gains optimization freedom. Inside the early-access build, JDK classes like Integer and LocalDate become value classes, which yields rather spectacular results in JShell:

jshell> Objects.hasIdentity(Integer.valueOf(123))
$1 ==> false

jshell> Objects.hasIdentity("abc")
$2 ==> true

jshell> LocalDate d1 = LocalDate.of(2025, 1, 1)
jshell> LocalDate d3 = d1.plusYears(1).minusYears(1)
jshell> d1 == d3
$8 ==> true   // two different "instances", same day — == returns true!

After years of writing about Valhalla, seeing this in JShell genuinely hits different.

The Valhalla team published the latest early-access build in March 2026 and is actively encouraging developers to test on real-world workloads. Worth noting: Nicolai Parlog on Inside Java Newscast #100 did an excellent job explaining value class semantics - the syntactic change is laughably small (the contextual keyword value before class or record), but everything else follows from it. Highly recommended.

And as a bonus - if JEP 401 enters preview, it will finally unblock the Vector API, which has been incubating since JDK 16 (currently in its eleventh round...) waiting precisely for Valhalla to properly express its types. As Java Code Geeks analyzed, JDK 27 or JDK 28 is the most likely window for that transition. Twelve to fourteen total incubations - sounds absurd, but the incubation model is working exactly as designed. Shipping a structurally wrong API permanently would have been the real mistake.

3. The Rest of the Candidates: Lazy Constants, Pattern Matching, and ZGC

Beyond Valhalla, there are several more JEPs that should land in JDK 27.

JEP 531: Lazy Constants (Third Preview) - the third preview round of what used to be called Stable Values, and before that, Computed Constants. In this iteration, changes include removing the isInitialized() and orElse() methods from the LazyConstant interface (as they didn’t align with the feature’s design goals) and a new ofLazy() factory method for creating stable collections - List, Set, and Map with pre-defined, lazily initialized elements. The new addition in the third preview - Set.ofLazy() - looks like this in practice:

class Application {
    enum Option { VERBOSE, DRY_RUN, STRICT }

    // Each Set element is initialized lazily, only on first access
    static final Set<Option> OPTIONS =
        Set.ofLazy(EnumSet.allOf(Option.class), Application::isEnabled);

    private static boolean isEnabled(Option option) {
        // Parse CLI, read config, query database... expensive operations
    }

    public static void process() {
        if (OPTIONS.contains(Option.DRY_RUN)) {
            return;  // Only this option gets initialized
        }
        // ...
    }
}

// And Map.ofLazy() enables even more expressive patterns:
static final Map<String, OrderController> ORDERS =
    Map.ofLazy(
        Set.of("Customers", "Internal", "Testing"),
        _ -> new OrderController()
    );

The key idea: every element in the collection sits in its own LazyConstant and initializes only on first access. Thread-safe by construction, and the JVM can constant-fold after initialization. The feature consistently matures with each iteration and is getting closer to finalization.

JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview) — the fifth (!) preview round, this time with no changes from the fourth in JDK 26. It has just advanced to Candidate status. It extends pattern matching with primitive types in all pattern contexts, adds tighter dominance checks in switch, and refines the definition of unconditional exactness. The fact that there are no changes paradoxically suggests finalization is close — the feature has matured to the point where there’s nothing left to fix. Been with us since JDK 23 - if you’re counting preview rounds on your fingers, you’ve run out of one hand.

JEP Draft 8329758: Faster Startup and Warmup with ZGC - still a draft (so it might not make it into JDK 27), but the direction is clear: the Z Garbage Collector should more efficiently allocate memory at application startup, minimizing the initial heap and OS overhead. Together with JEP 516 (AOT Object Caching with Any GC) from JDK 26, Project Leyden is steadily building the foundation for faster Java startup. The patient will be rewarded - though with Leyden, patience is measured in releases.

4. OpenJDK Bans AI-Generated Code: “Use It, But Don’t Commit It”

And now for the topic that electrified not just the JVM world.

OpenJDK published an Interim Policy on Generative AI that unambiguously prohibits contributing content generated by LLMs, diffusion models, or other deep-learning systems. The policy covers not just source code, but also text and images in Git repositories, GitHub pull requests, email messages, wiki pages, and JBS issues.

Interestingly - this isn’t a blanket AI ban. The policy explicitly encourages private use of generative AI tools to comprehend, debug, and review existing code, as well as for research related to OpenJDK Projects. The restriction applies solely to one step: creating and submitting content generated by those tools. Even sharing output with a colleague is fine — as long as you add a comment identifying it as AI-generated.

The rationale is three-layered, and it’s worth understanding because it describes the realities of large open source projects well.

First - reviewer burden. Generative AI makes it easy to create large quantities of “plausible-looking” code with “plausible-looking” tests that is nonetheless incorrect or poorly designed. As someone on Hacker News aptly summarized: the number and size of AI-assisted PRs have reached a tipping point, and “filtering out even the obvious ones is a drain” on the already limited time of human reviewers.

Second - safety and security. The JDK sits at the foundation of mission-critical systems worldwide. Plausible-looking but incorrect code poses a direct risk to those systems. OpenJDK can’t afford to be a testing ground.

Third - intellectual property. The Oracle Contributor Agreement (OCA) requires that a contributor own the IP rights to each contribution. Generative tools trained on copyrighted content create legal uncertainty here, which is the subject of active litigation.

The enforcement mechanism? Skara, the tool responsible for pull request workflow in OpenJDK, has been extended with a checkbox that contributors must check when creating a PR, affirming compliance with the policy. Of course, this is a trust-based mechanism. But the policy also lists some rather amusing “tell-tale clues” for spotting AI-generated content: an overly chatty, verbose commenting style, heavily structured responses with multiple headings, unnecessary code comments, gratuitously defensive programming, and... emoji characters. Official OpenJDK position.

Other clues include highly structured comments with multiple headings, unnecessary comments in code, gratuitously defensive programming, and the use of emoji characters. (...) In general, if something in a pull request seems uncannily cheerful or meticulous then you could be looking at AI-generated content.

What’s fascinating - not everyone in the Oracle ecosystem agrees. GraalVM has taken a diametrically opposite stance. Their policy on coding assistants explicitly states that contributors may use AI when preparing contributions, and that responsible use of such tools should increase development velocity and improve quality - e.g., by helping produce clearer documentation, broader test coverage, and more complete supporting changes. The document is inspired by the Linux kernel’s policy, which follows the same path. GraalVM’s key condition: the human submitting a change remains responsible for the entire contribution, must understand and be able to defend every piece of code, and if they can’t -the change gets rejected. But it’s accountability for quality, not a ban on the tool.

So we have a situation where two projects under Oracle’s umbrella - OpenJDK and GraalVM - occupy diametrically opposite positions. OpenJDK says “don’t commit AI-generated code in any form,” GraalVM says “use it, but take full responsibility.” This isn’t a contradiction - it reflects different contexts. OpenJDK is the platform foundation on which mission-critical systems globally depend, with a rigorous OCA process and a vast base of external contributors with varying levels of experience. GraalVM is a smaller project with a more specialized community, where maintainers know their contributors better. But the contrast is striking.

Looking more broadly, OpenJDK isn’t alone in its approach - QEMU adopted a similar ban, r/programming banned AI-generated content, Debian debated and... decided not to decide (classic Debian). And on the other side - GraalVM and the Linux kernel bet on individual responsibility instead of a blanket ban. I see a fascinating paradox here: AI tools are changing how we write code every day, yet the open source community doesn’t have a unified answer, even within the same ecosystem. This dissonance will only grow - and it’s a topic we’ll be discussing for a long time to come.

PS: If you want to discuss this paradox in person - join us at NY Tech Week, June 2 in New York, where Tomasz Lelek and I will be talking about Vibe Engineering and how AI is (or isn’t) changing the way we work with code.

PS2: In the meantime - download that Valhalla EA build and test it on your workloads. Seriously. After all these years of waiting, feedback from real users is the best thing we can do for Java.

This is one of those weeks where you have to set aside the technology and talk about the elephant in the room. When the company that stewards Java lays off 18% of its global workforce, and its CEO publicly says “the code that Oracle is writing, Oracle isn’t writing - our AI models are writing it,“ it’s hard to pretend this is “just another restructuring.”

But at the same time, paradoxically, this has also been one of the best periods for the Java AI ecosystem ever. So today we’ll try to piece these two pictures into a single coherent narrative. Fair warning: it won’t be easy, but I hope it will be educational.

On March 31, 2026, around six in the morning Pacific time, Oracle employees around the world started receiving emails. Not invitations to a meeting with their manager, not a heads-up from HR. Emails. From “Oracle Leadership.” Before breakfast.

According to data that leaked over the following days, the layoffs affected up to 30,000 people, roughly 18% of Oracle’s global workforce. CNBC confirmed the scale from two independent sources. The company set aside a restructuring budget of around $2.1 billion, mostly for severance. TD Cowen estimates the layoffs will free up $8 to $10 billion in annual cash flow. Money that, as you can easily guess, will go toward building AI data centers. Oracle’s capex for fiscal year 2026 is around $50 billion, $15 billion more than the company told Wall Street just a few months ago.

But it’s not the numbers that hurt the most. It’s the people.

Among those laid off was Sharat Chander, Head of Developer Community Engagement at Oracle, a person who spent 16 years (first at Sun Microsystems, then Oracle) building what you can, without exaggeration, call the largest developer ecosystem on the planet. His farewell post on LinkedIn was one of those that’s hard to read without feeling something:

So what does this mean for Java itself? At first glance: nothing. Oracle has repeatedly made it clear that the JDK, OpenJDK, and the entire six-month release cadence machinery is a key asset. Georges Saab, Chad Arimura, and the Java DevRel team are (for now) still in place. But it’s hard to watch the layoff of Sharat, the person who WAS Oracle’s community engagement, and not feel uneasy. Especially when we remember what happened at Sun right before the Oracle acquisition: 18% workforce cuts in 2008 (yes, the same percentage - you can’t make this up), another 3,000 during the deal delay in 2009, and then James Gosling, Tim Bray, and Simon Phipps walking out the door within months of the close. The community-facing roles were among the first to go then, too.

And then there’s that Larry Ellison quote: “The code that Oracle is writing, Oracle isn’t writing. Our AI models are writing it.“ That was said publicly. And regardless of how much of this is CEO hyperbole for analysts, 30,000 people just lost their jobs, and that narrative is their backdrop.

Remember JavaOne two weeks earlier? The “Java for an AI World” keynote, Java Verified Portfolio, Project Detroit, Helidon with LangChain4j - I wrote about it in more detail in vol. 167. Back then it looked like a bold ecosystem pivot. Today, in the context of the layoffs, that same keynote reads a bit differently. “Java for an AI World,” but not necessarily for all the people who built it.

And here we arrive at the paradox of this edition. Because regardless of what Oracle the corporation does, the AI ecosystem on the JVM has never looked better. And this isn’t hype - these are concrete developments from the past two weeks. JavaOne gave us “AI World” in a keynote, but the real answer from the community is visible in the projects that appeared right after.

-Let’s start with the biggest one. On March 30, Guillaume Laforge announced the GA release of Agent Development Kit for Java version 1.0.0 from Google. A full-fledged, code-first framework for building AI agents in Java, with Human-in-the-Loop (built around a ToolConfirmation mechanism that elegantly pauses the LLM flow and waits for approval), A2A Protocol support (agent-to-agent communication), sessions via Firestore and Vertex AI, and LangChain4j integration. Plus a Dev UI identical to the Python counterpart.

This is big. Google, a company that in the AI context is associated primarily with Python, is saying outright: Java is a first-class citizen in our agent stack. Guillaume wrote an excellent blog post about building a multi-agent “Comic Trip” application using ADK, complete with Google Maps integration, Firestore persistence, and a UI generated by Antigravity. I recommend it as an example of what building agents on the JVM looks like in 2026 - without pretending it’s Python.

And since we’re talking about people who do more than they say (while saying a lot): James Ward rallied the community and launched ai4jvm.com. A curated catalog of literally everything AI on the JVM: agent frameworks (Spring AI, LangChain4j, Embabel, Koog, Google ADK...), inference engines, code assistants, key people, educational resources. Not another awesome-list on GitHub, but a properly built site with a clear taxonomy that gives you a real picture of how vast this ecosystem has become.

James is everywhere right now: from episode 200 of the AWS Developers Podcast (with Josh Long, where the cited Java MCP SDK vs Python benchmarks are... encouraging: 0.835ms latency vs 26.45ms), tthrough JavaOne presentations on MCP and agent skills, to his SkillsJars project for packaging and distributing reusable AI agent skills as Maven/Gradle JARs (discover via Maven Central, load on demand in Claude Code or Spring AI), and the javadocs.dev/mcp server that gives AI agents structured, up-to-date access to Java library documentation instead of relying on stale training data.

The very existence of something like ai4jvm.com is telling. Just a year ago, when I wrote Hitchhiker’s Guide to AI in the Java Galaxy, the ecosystem fit into one (albeit long) article. Today it needs its own portal (and soon probably a search engine).

But agents aside, plenty is happening at a lower level of abstraction too. On April 2, TornadoVM 4.0.0 shipped with the thing I’d been personally waiting for: a native Apple Metal backend enabling heterogeneous compute directly on Apple Silicon. For those who haven’t followed previous editions, TornadoVM is an OpenJDK plugin that transpiles bytecode at runtime to OpenCL C, NVIDIA PTX, or SPIR-V, automatically running Java programs on GPUs, FPGAs, and multi-core CPUs. Version 4.0 adds Metal to that arsenal, along with SIMD shuffle and reduction intrinsics in the PTX backend, a new withCUDAGraph() method on TornadoExecutionPlan, and support for both JDK 21 and JDK 25.

I currently started experimenting with TornadoVM 4.0 and updated my Llama benchmarks - results soon.

What does this mean in practice? MacBook users on M1/M2/M3/M4/M5 can finally use native GPU acceleration without OpenCL workarounds. And given how many people in the Java community work on Macs, and that GPULlama3.java is one of the most interesting projects in this space, the Metal backend opens it up to an entirely new group of developers.

On a side note, because it fits the theme of a community that’s doing its own thing: Mark Sailes and Lee Gilmore just launched StudyFromExperts, an educational platform targeting advanced AWS practitioners. Their pitch is simple: most training material is written for people just starting their cloud journey, while senior engineers and architects are left to fend for themselves. Mark is well known in the Java/serverless ecosystem, so I’ll be watching what grows from this.

See the pattern? Google builds an agent framework. AWS evangelizes the ecosystem. Manchester delivers Metal on GPU. JetBrains bets on agent orchestration. Sailes and Gilmore build an educational platform. None of them are waiting for Oracle.

PS: If you’re by any slight chance reading this, Sharat: thank you for those 16 years. The Java ecosystem wouldn’t be what it is without your work. And whatever comes next, the community remembers.

PS2: I recommend ai4jvm.com as a starting point for anyone who wants to understand just how vast the AI ecosystem on the JVM is today.

As a hub for the “Friends of OpenJDK,” Foojay.io gathers a rich collection of articles written by industry experts and active community members, offering valuable insights into the latest trends, tools, and practices within the OpenJDK ecosystem.

This month’s main feature comes from María Arias de Reyna Domínguez, Java Champion working at IBM as part of the OpenJDK team, who published a three-part deep-dive into how Project Leyden is improving Java performance. There’s Part 1 covering the history and architecture of the solution, and Part 2 showing how to actually use the AOT cache and presenting test results.

But I wanted to focus specifically on Part 3, because while the first two installments provide necessary background, Part 3 is where things get genuinely practical - and arguably where the real “engineering” starts. It walks you through diagnosing an AOT cache on a real, non-trivial Quarkus application with a dedicated tooling that lets you understand why you’re getting the performance you’re getting (or not getting).

How is Leyden improving Java Performance? Diagnosing Your Leyden AOT Cache - A Practical Walkthrough

What is inside the Ahead of Time Cache?

Ideally, an AOT cache would simply include everything needed to allow a production run to skip straight through to its warmed up state. However, in practice training runs don’t always cover all the things that can happen at runtime and hence that the assets contained in any generated AOT cache will be more or less complete.

In order to have some idea of how effective a training run has been it’s helpful to be able to look at a cache and see what is in it. Full details of the tooling that allows you to do that are presented in part 3 of this blog series. However, in order to prepare for that, we need to provide an overview of the JVM assets that end up in the cache and how the JVM uses them. We will follow up with some examples to show how effectively this improves startup and warmup.

So, let’s take a deeper look at what exactly is inside the AOT Cache. There are several different ways of classifying the contents:

The most straightforward way to classify AOT cache assets is to distinguish between Static and Dynamic data.

Static assets are data that are available in or directly derived from bytecode, data that exist, even if only implicitly, at build time.

Dynamic assets are data that get generated, or are collected, at runtime as a side-effect of execution. Some of them record information that can be used to trigger compilation and drive feedback-driven optimizations, including speculative optimization, beyond what an ahead-of-time compiler would be able to do. They can also include the compiled code that is generated as a result of that compilation.

Finally, they include training data, created as a training run progresses to track what the JVM has done and why. Training data identify what JVM assets need to be stored into the cache when it is created. They are also installed in the cache, indexing the other assets and helping identify how to use them in production.

We can also distinguish two types of data depending on their purpose:

On one hand, there is the JVM data - metadata, heap data and code. This is a network of C++ objects that are used during normal JVM running to define and regulate Java execution. These objects must always exist, even when running without a cache, in order for the JVM to be able to run an app. This object network needs to be dumped to the archive on disk in a format that allows it to be quickly and correctly restored to the relevant memory areas of the production JVM in a valid (C++ Object) format and layout that matches the JVM’s expectations.

On the other hand we also have Leyden’s own Cache Management Data, i.e. training data, which exists specifically to support creation and consumption of AOT cache. Training data are also saved and restored as C++ object data but the format and layout of these objects is determined solely by the Leyden cache management code. Its sole purpose is to track and regulate what assets get written to the AOT cache after training completes and what assets can or should be restored in production.

Let’s see in detail what each data type means.

JVM Metadata

Metadata stored in the AOT cache is a superset of what was stored in a CDS archive. The subset which overlaps with CDS is the static metadata. The latter represents the structure and hierarchy of classes in JDK and application code. Primarily, it helps avoid the cost of parsing bytecode, as it is in the same format as the JVM’s own internal metadata model: classes, methods, fields, inheritance between classes,... which can be mapped directly into memory. Having this information stored in the cache speeds up the time the Hotspot takes to decode the different class files, and to build the dependency graph.

While starting the application, the Java Heap memory gets filled with objects and instances that are going to be used during runtime. Some of those heap data objects can be cached too because they are quite predictable, like Strings hardcoded in the source code, java.lang.Class instances, some content of class static fields, objects needed to run lambdas, the class graph module,... Those are all assets that are created in memory in the same way on every run.

The heap data cached at the moment is restricted to very specific cases as it has to behave exactly the same on each and every run, but the type of data cached is expanding on each JDK version.

JVM Profile and Linkage Data

The cache also includes dynamic JVM metadata i.e. MethodCounter, MethodData and ConstantPoolCache objects. These objects are created and attached to the static metadata methods and classes and their content is updated as a side-effect of executing method code.

MethodCounter objects track how often the method they are attached to has been called. They are primarily used to trigger compilation via the baseline (C1) or optimizing (C2) compiler. The interpreter increments a method’s call count up to a threshold before scheduling a C1 compile, possibly including code that gathers further profile information. Instrumentation code in (Tier 2 andImage description 3) C1 compiled methods also updates the call count and when a higher threshold is reached either upgrades to (Tier 4) C2 compiled code or reverts to (Tier 1) C1 compiled code which includes no instrumentation

MethodProfile objects record detailed information about their associated method’s hot and cold paths, argument types and other details of how it executes, most notably any history of speculative deoptimization. Apart from the deoptimization case, which applies for both C1 and C2 code, MethodProfile objects only receive updates via instrumentation code in (Tier 2 and 3) C1 compiled methods.

ConstantPoolCache objects are attached to a clasImage descriptions and track the linkage of call and field access sites in any of the class’s methods. Prelinking avoids work at the first call or first field access and this is especially valuable when the call is an invokedynamic i.e. the bytecode that implements a lambda invocation.

Linking a lambda involves running Java ‘bootstrap’ code that identifies a private class that owns the bytecode for the lambda body, asking it to construct and return a MethodHandle that can be used to execute the target. If a lambda can be run during training then the target class and method can be pre-loaded and the MethodHandle stored in the heap and linked from the ConstantPoolCache, avoiding the need to run the ‘bootstrap’ in production. If the lambda is executed repeatedly in production the called bytecode may even be inlined into the compiled code for the caller. Effectively, executing as lambda in training removes all setup overheads in production, making lambdas as cheap to use as a direct method call.

JVM Code and Code Management Data

AdapterHandlers are a set of utilities used by the Hotspot to marshall method parameters when performing certain types of call. AdapterHandlers can be cached, avoiding the need to generate them on demand. They are identified by their AdapterFingerprint and indexed via a table of AdapterHandleEntry objects.

Alongside these handlers various StubBlobs needed by the runtime are also cached. These blobs contain JITted code that implements one or more ‘stub’ routines. Stub routines include architecture- and OS-specific code used by the JVM to perform operations that are hard to write in a platform agnostic way. Examples include: flushing code regions after update by the JIT or call linker, unwinding the stack when an exception occurs, replacing a compiled stackframe with one or more interpreter frames when execution of a deopt trap forces a bail-out etc. There are also many stubs that provide hand crafted, high-performance implementations of math, crypto or memory copy methods that are used in place of Java implementations on some architectures, especially where hand-crafted code can use specialized hardware instructions to outperform the JIT compiler. Much of the stub and adapter code has to be generated before the JDK can fully startup. Storing it in the cache and reloading it in production provides a small but noticeable performance improvement.

Leyden premain also includes CompiledMethods, i.e. pre-compiled Java methods, in the cache. This includes both C1 and C2 (Tiers 1 - 4) and in some cases different tier compiled versions of the same method. Having compiled code immediately available, especially Tier 4 code, is an enormous boost to performance. Lower tier code may be useful when the method only reached that tier during training or as a fallback if we need to deoptimize and reprofile. Pre-compiled Java methods are an enhancement we expect to add soon to the mainline JDK.

Leyden Training Data

Training data is part of the Leyden specific code. It tracks which methods have actually been loaded, executed, and used during the training run and how they have been used. Normally all loaded classes have associated class training data, but these may be omitted if, say, the class is loaded by a custom (user-defined) loader, is modified by an agent or fails to resolve because of linkage errors.There is a usage threshold which means that only methods that have been executed above that threshold will have associated method training data. Likewise, compiled method training data only exists for methods actually compiled during training. This helps both in keeping a smaller footprint in the cache and removing less useful data so processing the cache is faster.

How Do I Know Leyden Is Helping?

Depending on how well you train your deployment you may see different improvements in time to reach application start (startup time) and time to reach peak performance (warmup time). Log output is one useful way to measure these two metrics but the details will depend on what monitoring capabilities are available in your test or production environment. However, simply measuring these two times (or even recording warmup profiles) doesn’t help with the problem of explaining why, for some given training regime, you get a specific improvement or perhaps, in some cases, no measurable improvement.

For any given AOT cache (or set of alternative caches) it is very helpful to have some idea of what assets were included or excluded in the training set, which ones were written into the cache and what benefit they provide during a production run. In particular, it is useful to have both aggregate statistics and information on individual assets and their relationships. The Leyden project has provided a tool precisely to address these needs. Let’s see a practical example of how to diagnose an AOT Cache.

For the purpose of this article, we are going to use the following example application: https://github.com/Delawen/bad-good-cache

This is a web application that has a simple API and a basic html interface to use it.

The first thing we need to do is to compile this application on the root folder:

$ mvn clean package

Training the application

Once we have the jar created, we use it to start a training run:

$ java -XX:AOTCacheOutput=target/app.aot -Xlog:aot+map=trace,aot+map+oops=trace:file=target/aot.map:none:filesize=0 -Xlog:class+load=info,aot+resolve*=trace,aot+codecache+exit=debug,aot*=warning:file=target/training.log:level,tags -jar target/quarkus-app/quarkus-run.jar

The arguments we are going to use are the following:

• -XX:AOTCacheOutput=target/app.aot Which will create an AOT file called app.aot

• -Xlog:aot+map=trace,aot+map+oops=trace:file=target/aot.map:none:filesize=0 Which will create a map file that indexes and describes the previously created AOT file.

• -Xlog:class+load=info,aot+resolve*=trace,aot+codecache+exit=debug,aot*=warning:file=target/training.log:level,tags Which will generate training log files with relevant information

$ oha --urls-from-file src/main/resources/urls.txt -n 100

Now that we have trained the application, let’s stop it with ctrl+c. It will take some time to stop while it builds the cache. It will do both the training and assembly steps at once.

We should have created three types of files:

• target/app.aot : The AOT cache itself

• target/aot.map : The map file

• target/training.log : The logs for the training run

Now that we have the AOT cache, we can start a production run, in which we will also save log files:

$ exit

The arguments we are going to use are the following:

• -XX:AOTCache=target/app.aot Make use of the AOT file called app.aot

• -Xlog:class+load=info,aot+resolve*=trace,aot+codecache+exit=debug,aot*= warning:file=target/production.log:level,tags Which will generate a production log file with relevant information

On this run, we created the production.log file.

Analyzing the Cache

After using it, we can stop it and analyze how the AOT Cache behaved with our AOT Cache diagnostics tool: https://github.com/Delawen/leyden-analyzer

The first step is loading all the information into the tool, to run a proper analysis:

\> load aotCache --background target/aot.map

\> load trainingLog --background target/training.log*

\> load productionLog --background target/production.log*

Now we are ready to start our analysis. A good place to start is the info command that shows a summarized version of what is inside the cache:

Are we training the right thing?

The first thing that should catch our attention is that there’s more than 10% of classes that were used on the production run but were not cached. That’s not usual, so let’s dig into whatImage description those classes are. There are hundreds of them, so if we filter by our package name, that would make our exploration easier:

What does this mean? Let’s take a closer look:

This class was not loaded during training but it was loaded during production. Something went wrong with our training.

We can explore the class org.cutecats.rest.json.CatPhotoGenerator by looking at the source code. There, we discover that it should be used by org.cutecats.rest.json.CatResource.

So, this class was loaded both on training and production runs, and the metadata is included in the AOT Cache. But for some reason, none of its methods were profiled during the training run. This means that our training run did not make extensive use of this class. Maybe we should take a look at our training run.

And indeed, there is an obvious mistake: the urls.txt file that oha used to create the requests only contains the static html pages. None of our Java classes are executed, although Quarkus loaded them at the beginning as services.

Let’s run again the training, changing the url to the Java endpoints instead of the html pages: http://localhost:8080/cats and http://localhost:8080/list

Don’t forget to remove the log and aot files from target/ after each try to have clean runs (the clean on the maven command should do that).

If we analyze the results again with our tool, we should see a different result:

We have increased the percentage of the classes used (96%) in production that were cached compared to our last attempt (89%). That’s an improvement.

Did we load all relevant classes during Training?

Let’s check again for classes loaded in production that were not cached:

Something is still not working as intended. Maybe we should approach this from the other side: are we executing some testing code that replaces the real production code that should be executed during training?

Let’s check if there’s something being stored in the cache that we don’t really need:

We can see a suspicious class called DummyPhotoGenerator. That’s supposed to be used only for testing purposes, not for real training and production. Using DummyPhotoGenerator instead of the CatPhotoGenerator class is making the code and classes used by CatPhotoGenerator not being used. If we explore our source code, we will discover that there is a “test” argument on the /cats endpoint that distinguishes between testing and production.

To fix our training, we have to call the endpoint /cats with a test=false argument. Because the training run is not a test run.

The training run has to be as close to production as possible. If we use test classes, not only will they be stored in the cache and be loaded on production run, but they may also hide real production code from being trained.

Let’s try again, now using http://localhost:8080/cats?test=false in the urls.txt file.

We have increased a bit more the percentage of classes loaded, which is always a good sign. Image description Do we have any other classes loaded during production that were not cached during training? Are there any testing classes loaded during training or production runs?

We made sure that:

• All our classes used in production are included in the cache

• None of our testing classes are included in the cache

Although we still don’t have the aspiring ideal 100% classes cached, we are really close (98%) and we can be happy with the list of classes cached. We can now focus on how good the profiling of the methods is.

Are our methods properly trained?

Maybe you already noticed another important information we have been ignoring until now: all our classes are labelled as “[Untrained]“. Let’s take a closer look at that.

Profiling is done on each method independently, so let’s take a look at one of our methods that we know should be well trained. The describe command is pretty self explanatory on this case:

Let’s follow the recommendation and do more requests during the training run.

$ oha --urls-from-file src/main/resources/urls.txt -n 10k

And with 10 000 requests done, we can see that we got our method completely profiled and compiled to the higher level:

There’s still more improvements that can be done to the training that will greatly depend on your application, but now we have all the basics covered.

Also on Foojay This Month

Foojay Podcast #92: Java 26 Is Here: What’s New, What’s Gone, and Why It Matters in 2026 - Frank Delportehosts Simon Ritter (Deputy CTO at Azul) and Loïc Mathieu (Lead Software Engineer at Kestra.io) for a thorough walkthrough of Java 26. Ten JEPs in total - five new features, five preview/incubator rounds. Highlights include JEP 500 (Prepare to Make Final Mean Final), JEP 517 (HTTP/3 for the HTTP Client API), JEP 504 (the final removal of the Applet API - farewell, old friend), JEP 516 (the aforementioned AOT Object Caching with Any GC), JEP 522 (G1 GC throughput improvements), and the sixth preview of Structured Concurrency (JEP 525). The discussion also touches on which Java versions companies are actually using, the ongoing Vector API saga (eleventh incubator, waiting on Valhalla), and what Java still needs to be truly “AI-ready” - with code reflection from Project Babylon and TornadoVM mentioned as key pieces. Solid listen for staying current with the release cadence.

How We Built a Java AI Agent by Connecting the Dots the Ecosystem Already Had

As I mentioned week ago, the team behind JobRunr published a fascinating writeup about ClawRunr (nicknamed “JavaClaw” by the community - and they’ve apparently stopped correcting people). It’s an open-source AI agent runtime written in pure Java, and the interesting part isn’t the AI - it’s how boring the architecture is, in the best possible way. Spring AI for LLM calls, Spring Events for multi-channel routing (Telegram, browser, whatever comes next), JobRunr for reliable background job scheduling with retries and dashboards, Spring Modulith for clean module boundaries. The DefaultAgent class is 20 lines.

The foojay.io article’s central argument is provocative: the hardest problem in an AI agent isn’t talking to the LLM - it’s reliable task execution. Scheduling a “summarize my emails every morning at 8” requires retry logic, persistence across restarts, and visibility into failures. That’s a background job problem, and Java has been solving those for decades. Within three days of release, someone in the community had already written a Discord plugin without touching the agent core. The Java ecosystem just... works for this.

Eclipse GlassFish: This Isn’t Your Father’s GlassFish

OmniFish team tackles the most persistent myth in the Jakarta EE world: that GlassFish is a dead, unsupported, development-only toy. Eclipse GlassFish: This Isn’t Your Father’s draws a clear line between Oracle-era GlassFish (pre-2018, stagnant releases, limited support) and Eclipse GlassFish 7.0+ (since 2022 - monthly releases, Java 11–25 support, Jakarta EE 11 compliance, several MicroProfile APIs, commercial long-term support from OmniFish).

There’s also a new embedded GlassFish mode that lets you spin up a Jakarta EE environment programmatically - useful for testing and microservice-style deployments. If your mental model of GlassFish stopped somewhere around 2014, this is a good reality check.

Managing Native Memory in Java: Arenas, Malloc, and Custom Pools

Managing Native Memory in Java: Arenas, Malloc, and Custom Pools by David Vlijmincx guide to the FFM API’s memory management primitives. David walks through the four built-in Arena types (global, ofAuto, ofConfined, ofShared) with their respective tradeoffs between lifetime determinism and thread safety, then goes deeper - implementing a custom LoggingArena, using raw malloc/free via FFM for full control, building reusable memory pools, and slicing segments for zero-allocation sub-regions.

The article does a good job of presenting the spectrum from “safe and easy” (use Arena.ofConfined() in a try-with-resources) to “you’re basically writing C now” (raw malloc with manual lifecycle management). If you’ve been curious about going off-heap with modern Java but found the official docs a bit abstract, this is a good entry point.

The Java in Education Catalog Now Has a Beautiful Home

by Frank Delporte and Igor De Souza

Remember Igor’s earlier piece on the Java Education Catalog - the community-driven GitHub repo collecting Java educational resources?

It now has a proper website at education.foojay.social, built using a workflow borrowed (with permission) from James Ward‘s excellent ai4jvm.com site. The catalog includes JetBrains tutorials, Devoxx4Kids resources, Pi4J/JBang examples for Raspberry Pi, and books like “Raising Young Coders.” Contributing is as simple as editing a SPEC.md file and opening a PR. A GitHub README is functional, but an actual browsable website is what gets educators - who aren’t necessarily deep in the coding ecosystem - to actually discover and use these resources.

Nice community work.

And that’s all, folks.

This time the material practically wrote itself. JDK 26 shipped, JHipster caught up with Spring Boot 4, Kotlin keeps polishing K2 like it’s a family heirloom, JetBrains reshuffled its product strategy, and the JVM agentic ecosystem quietly got its first serious reference implementation. On top of all that, the community had one of its best months for thoughtful technical discourse — debunking performance myths, formalizing benchmarking standards, and connecting polyglot runtimes. Let’s dive in!

1. March: The Rest of the Story

Just as a reminder - JDK 26 went GA on March 17th - ten JEPs across five categories, and more substance than most non-LTS releases deserve. The infrastructure headline is JEP 516 (Ahead-of-Time Object Caching with Any GC), which extends Project Leyden’s AOT cache to all garbage collectors — including ZGC, which was previously incompatible due to its advanced memory layout. The fix is elegant: instead of directly memory-mapping cached objects in a GC-specific format, they’re now loaded sequentially from a neutral, GC-agnostic representation. JEP 522 squeezes up to 15% more throughput from G1 by reducing synchronization overhead between application and GC threads. And JEP 519 brings HTTP/3 to the built-in HTTP Client API - a long-awaited modernization that brings QUIC-based transport to Java’s networking stack.

On the security front - and this tends to get lost in the JEP noise - JDK 26 delivers a quietly impressive batch of improvements. The headline is Hybrid Public Key Encryption (HPKE) support per RFC 9180, accessible through the familiar Cipher API with a new HPKEParameterSpec class. HPKE combines a KEM, KDF, and AEAD algorithm into a modern encryption scheme that’s already widely used in protocols like TLS ECH and MLS - and Java finally speaks it natively. For now it’s limited to traditional algorithms (X25519 and friends), with PQC variants coming once the IETF draft matures. Alongside HPKE, the jarsigner tool now supports ML-DSA signatures — meaning you can sign JARs with a quantum-resistant algorithm today. Not “in preview,” not “experimental” - actual production jarsigner support. The post-quantum transition isn’t theoretical anymore; it’s in your build pipeline.

As Sean Mullan notes in his traditional JDK security roundup - which remains the single best resource for tracking Java’s security evolution release by release - these changes collectively push Java’s crypto stack further toward post-quantum readiness while cleaning out the legacy cruft that’s been accumulating for decades.

For teams still on JDK 21: Oracle’s permissive NFTC licensing for JDK 21 ends in September 2026. Migration planning should be well underway.

Ronald Dehuysser and the team at JobRunr launched ClawRunr (also known as JavaClaw) - an open-source AI agent runtime built on JDK 25, Spring Boot 4, Spring AI, and JobRunr. It’s essentially a Java port of OpenClaw - the Node.js personal AI assistant we discussed back in the OpenClaw/Peter Steinberger edition.

Let me start with strong statement - this is one of my favourite Duke personas ever.

What makes ClawRunr architecturally interesting: agents can self-schedule cron jobs, one-shot tasks, and recurring work through tool calls, with JobRunr persisting everything across restarts. Skills are loaded at runtime via SKILL.md files dropped into a workspace directory - no recompilation, no redeployment. Supports OpenAI, Anthropic, and Ollama out of the box - to run entirely on your hardware. The stack reads like a Spring Boot 4 showcase application - which, strategically, may be exactly the point.

Combined with SkillsJars (Maven Central as a package manager for AI agent skills, from last month’s ROTS) and the Open Liberty MCP feature (more on that below), the JVM agentic ecosystem is coalescing faster than I expected. Someone should probably write some overview of this trend... 😉

JetBrains made two significant strategic moves this month that read as a single coherent narrative. First: core JavaScript and TypeScript support is now free in IntelliJ IDEA. Historically, robust web development was a primary differentiator for the paid Ultimate Edition, often forcing JVM developers to context-switch between IntelliJ for backend and VS Code for frontend. This move directly targets that friction = and acknowledges that the modern developer persona is rarely confined to a single language.

Second: Code With Me enters maintenance mode starting with IDE version 2025.1, with full decommission by 2026.3. JetBrains is transitioning from the plugin’s peer-to-peer relay system to a thin-client model powered by JetBrains Gateway and the Remote Development protocol. For JVM engineers, this means moving toward a headless backend execution model — the JetBrains Client handles UI, the heavy lifting happens server-side.

Together, these moves signal JetBrains consolidating around two pillars: IntelliJ as the unified polyglot hub (countering VS Code), and Gateway as the enterprise-grade remote development infrastructure. The collaborative plugin era is over; the protocol-driven era begins.

However, that’s not all from JetBrains, they had quite a busy month seemingly.

JetBrains introduced new inspections in IntelliJ IDEA targeting the intersection of Kotlin Coroutines and JDK 21 Virtual Threads - a pain point that’s been growing since Loom went GA. The inspections identify risky patterns like making blocking calls within a coroutine scope without the appropriate Dispatcher. This is particularly critical for Spring Boot developers leveraging Virtual Threads: inadvertently blocking a carrier thread or “pinning” it can cause performance regressions that are devilishly hard to debug at runtime.

Managing dual concurrency abstractions - Coroutines and Virtual Threads - within a single codebase remains one of the trickiest challenges in modern JVM development. These guardrails won’t solve the fundamental design tension, but they’ll catch the most common mistakes before they make it to production.

But the crème de la crème dropped just yesterday. JetBrains announced Central - and this one reframes everything above into a single strategic picture. Central is positioned as “the control and execution plane for agent-driven software production” — a layer that connects IDEs, CLI tools, AI agents (not just Junie, but also Claude Agent, Codex, Gemini CLI, or custom-built solutions), and infrastructure into a unified system with governance, cost attribution, and observability.

Think of it as: free JS/TS support gets more developers into IntelliJ, Gateway provides the headless execution model, Air from two weeks ago coordinates human-agent workflows - and Central sits on top as the enterprise control plane that makes it all manageable at scale.

The reasoning behind Central is straightforward if you’ve been paying attention to how AI is actually used in engineering organizations today: most developers already use AI at work, and coding agent adoption is accelerating fast - but the impact remains overwhelmingly limited to individual productivity. Almost nobody has AI meaningfully integrated across the entire software development lifecycle, from code review through the release pipeline. The gap between “individual developer productivity” and “organizational software delivery” is precisely where Central aims to land - with policy enforcement, identity management, semantic context across repositories, and intelligent routing to the right models for the right tasks.

EAP launches Q2 2026 with design partners. Whether this becomes the “Kubernetes for AI agents” or just another enterprise dashboard remains to be seen - but the ambition is unmistakable. JetBrains isn’t just making tools anymore. They’re building the operating system for how software gets produced in the agentic era.

Jonathan Vogel post “Java Is Fast. Your Code Might Not Be” - based on his DevNexus talk - sparked one of those community discussions that ends up being as valuable as the original article. The premise is absolutely right: application-level inefficiencies can bottleneck even the fastest runtime, and Vogel’s demo numbers are genuinely impressive (from 1,198ms down to 239ms, heap from 1GB to 139MB, same app, same JDK). But the Hacker News thread turned into a fascinating conversation about which of the cited anti-patterns still actually matter in 2026 - and it (once again) inadvertently exposed how much the JVM has changed under the hood while our collective intuition hasn’t always kept up. The StringBuilder pattern, for instance, is one many of us learned early in our careers, and it made perfect sense at the time. But since JEP 280 in Java 9, the compiler leverages invokedynamic and StringConcatFactory to optimize concatenation strategies dynamically - which means the runtime has been quietly handling this for us for years now.

The ensuing discussion turned into a genuinely useful conversation about where performance gains actually live in modern Java. The real culprits today - excessive object allocation, deep abstraction layers in popular frameworks, using Streams on hot paths where a simple loop would suffice, the lack of “mechanical sympathy” regarding CPU caches - got a thorough airing.

The consensus landed in a good place: the “Java is slow” myth is dead, but it’s been replaced by a subtler truth that profiling is a mandatory discipline, not a nice-to-have. Tools like JFR and async-profiler are where the signal is, and the JVM has gotten so good at optimizing the basics that our energy is better spent elsewhere. Honestly, the whole episode was a healthy reminder for all of us - myself included - that it’s worth periodically revisiting our performance assumptions against the current state of the runtime. The JVM of 2026 is a very different beast than the one we formed our mental models on.

Thanks Jonathan, can’t wait for the followup articles!

On a related note, Quarkus is formalizing a benchmarking methodology that moves beyond vanity metrics. Instead of raw process startup time, they’re measuring “Time to First Request” and Resident Set Size (RSS) - the metrics that actually matter for Kubernetes deployment density. In “Peanut” configurations (0.5 vCPU, 256MB RAM), Quarkus demonstrates sub-100ms response times and ~20MB RSS footprints in native mode. The testing environment uses Hyperfoil for load generation with strict hardware isolation via taskset and cgroups for deterministic results.

Even better: the new quarkus-benchmarks repository now provides transparent, reproducible comparisons against .NET minimal APIs and Go - not just internal JVM-versus-JVM battles. Java proving parity on startup and memory with .NET and Go in container-constrained environments is the kind of data we’ve been waiting for.

Josh Long hosted discussion with Cay Horstmann - the author of the definitive Core Java series - durign the Java One. For anyone who learned Java from Horstmann’s textbooks (and that’s... most of us - not many technical books has 12 Editions(!)), it could be a really interesting listen.

Pi4J, the Java IO library for Raspberry Pi, officially joined the Commonhaus Foundation. Frank Delporte (Java Champion, technical writer at Azul) described the move as ensuring the project survives beyond its current team. Pi4J follows Micronaut’s January announcement of its own application to Commonhaus. The consolidation of JVM open source under a neutral, sustainable foundation continues - and that’s unambiguously good news for everyone who depends on these libraries. Pi4J V4.0 also shipped on February 20th.

The beta of Open Liberty 26.0.0.3 ships with updates to Model Context Protocol integration for Jakarta EE applications. New ContentEncoder and ToolResponseEncoder interfaces for finer control over encoded responses, plus session-based request IDs via a RequestID record. This makes Open Liberty one of the first enterprise Java application servers with first-party MCP support. Combined with the Jakarta Agentic AI initiative under the Eclipse Foundation, enterprise Java is taking the agent story seriously - and not just through Spring AI. The specification-driven path is advancing in parallel.

Did I mentioned somebody should write an article about it?

A developer retrospective on building a Kotlin CLI tool with GraalVM Native Image versus standard OpenJDK 21 highlighted sharp trade-offs. Using a KMP-compatible stack (Clikt, Ktor, Koin), the project achieved 10ms startup for the native binary versus 800ms on the JVM - an 80x delta on Apple Silicon M3.

The reflection metadata configuration remains the primary friction point. The community consensus: run the GraalVM tracing agent against a JUnit suite to exercise reflection paths and auto-generate reachability metadata. But critics raised a pragmatic point - for tools dependent on high-latency LLM APIs, JVM startup overhead is often negligible compared to network I/O. And since the chosen libraries are fully KMP-compatible, Kotlin/Native may now be a more efficient path for CLI tools, bypassing GraalVM’s configuration hurdles while maintaining similar performance profiles. Food for thought.

JetBrains announced Kotlin’s participation in GSoC 2026, with projects centered on the K2 compiler architecture, Kotlin Multiplatform tooling, and Kotlin/Wasm backend optimizations. The emphasis on K2 Intermediate Representation for advanced compiler plugins and KSP API refinement signals continued investment in post-KAPT build performance. Projects are structured in 175-hour and 350-hour tiers — a mix of library parity work within kotlinx and deep compiler engineering.

Two new projects push the JVM toward high-performance polyglot execution. swc4j compiles TypeScript directly to JVM bytecode using ASM 9.7, leveraging the Rust-based SWC parser via JNI. It maps TypeScript primitives directly to Java types (number → double), bypassing the GraalJS Polyglot API entirely - designed for environments where JIT-warmup delays and engine memory footprints are unacceptable.

Meanwhile, WebAssembly4J provides a unified API across Wasm runtimes (Wasmtime, WAMR, Chicory) with dual integration paths: JNI for Java 8/11 compatibility and Project Panama (FFM API) for Java 22+. For engineers who’ve been watching the Wasm-on-JVM space: the “black box” script engine era is giving way to more transparent, low-latency execution models where TypeScript and Wasm become first-class JVM citizens.

Finally, informational JEP draft: JDK Source Structure formalizes the internal architecture of the OpenJDK source repository. While it introduces no new features, it codifies the src/$MODULE hierarchy - share for platform-independent logic, strict OS/CPU-specific isolation - as the “single source of truth” for contributors. If you’ve ever wondered where to look in the jdk/jdk Git repo, this is now your definitive map.

When it will be moved from the draft, you can be sure I will get back to it.

2. Release Radar

Kotlin 2.3.20

Kotlin keeps polishing. Kotlin 2.3.20 marks a significant stabilization of the K2 compiler ecosystem with some language features that actually matter in daily work. The headline: name-based destructuring for data classes - extracting properties via explicit identifiers rather than positional indices. If you’ve ever refactored a data class and introduced a subtle bug because the second and third properties were both String - this is for you. Consider:

data class User(val name: String, val email: String, val role: String)

// Before 2.3.20 — positional. Swap email and role in the data class
// and this silently breaks:
val (name, email, role) = user

// With name-based destructuring — resilient to reordering:
val (name = name, role = role, email = email) = user

Also new: guarded when expressions - essentially if-predicates inside pattern matching branches, which eliminates the awkward nested-if-inside-when pattern that made complex matching feel clunky:

when (val result = fetchData()) {
    is Success if result.data.isNotEmpty() -> process(result.data)
    is Success -> handleEmpty()
    is Error if result.isRetryable() -> retry()
    is Error -> fail(result.cause)
}

Previously you’d either nest an if inside the is Success branch or split it into separate when blocks - neither of which read well. This syntax makes the intent immediately clear: the guard is part of the pattern, not an afterthought.

Beyond language features: experimental non-local break and continue in inline lambdas (a long-standing community request), and - crucially - JFR events for compiler phases, providing much-needed observability into build performance. K2-native incremental compilation is now the default for multi-module projects. The PSI preparation for the transition from context receivers to context parameters is underway. With full support for JDK 23 and Gradle 8.10, the ecosystem remains current.

The most impactful change for K2 adopters? The synchronization of the IDE analysis engine with the compiler backend should eliminate those “red code” inconsistencies that have plagued early adoption. If you’ve been holding off on K2 - this release is your signal to try again.

Release Notes

Staying in the Kotlin world: JetBrains announced direct support for Swift Package Manager dependencies in Kotlin Multiplatform. This removes one of the final significant hurdles to KMP adoption in iOS-heavy environments - CocoaPods integration has been a persistent source of friction, and the ability to consume Swift-only libraries directly through the KMP toolchain is a genuine quality-of-life improvement. The community reaction has been overwhelmingly positive. The beginning of the end for legacy CocoaPods workarounds? We can hope.

IntelliJ IDEA 2026.1

I hope you are not tired with JetBrains narrative for this month - IntelliJ IDEA 2026.1 shipped yesterday, as announced by 👓 Anton Arhipov together with 👩🏻💻 Marit van Dijk , Marco Behler , and Siva Prasad Reddy K in a 1-hour video walkthrough full of demos.

This release is where all the strategic moves we discussed above materialize into something you can actually download. The headline is the Agent Client Protocol (ACP) Registry - browse and install AI agents in one click.

Not just Junie and Claude Agent anymore: Codex, Cursor, GitHub Copilot, and any ACP-compatible agent now work inside IntelliJ natively. The Git worktrees integration is designed explicitly for agent workflows: work in one branch yourself, hand another off to an agent, keep moving. Agents can even query and modify your database sources directly. This is JetBrains Central’s vision, but at the IDE level - the IDE as an open platform for agentic development, not a walled garden.

For the JVM crowd specifically: first-class Java 26 and Kotlin 2.3.20 support from day one (as is tradition). Spring runtime insight lets you inspect injected beans, endpoint security, and property values without pausing execution - a feature that will save Spring Boot developers an embarrassing amount of time they currently spend on debug logging. Kotlin-aware JPA detects and fixes pitfalls like using data class and val fields on Jakarta Persistence entities - problems that silently corrupt your persistence layer because JPA was designed for Java’s mutability model, not Kotlin’s.

The polyglot story continues: C/C++ support via the CLion plugin (for teams mixing JVM with native code), JavaScript and TypeScript now free without an Ultimate subscription (what we already mentioned earlier), and native Dev Container workflows that let you open containerized projects as if they were local. Dependency sources are now auto-downloaded in the background - you always have full context for debugging and navigation.

This is, honestly, one of the most cohesive IntelliJ releases in a while. Every feature connects back to the same thesis: the IDE is becoming the integration point for a multi-agent, multi-language development system. Whether you buy the full JetBrains Central vision or not, the individual pieces are already making daily development measurably better.

What’s New page | What’s Fixed

JHipster 9.0.0

JHipster 9.0.0 reached GA after three beta releases. The headline: alignment with Spring Boot 4.0, cascading into Jakarta EE 10 and the modern JVM stack. JDK minimum bumped from 17 to 21, Node.js from 20 to 22. Frontend refresh: React 19 with react-bootstrap, Angular 21 with zoneless mode and signals, Vue with Bootstrap 5.

But for me, GraalVM native image support is even more interesting addition for cloud-native teams. Additionally, the entire generator codebase has been rewritten in TypeScript. So for JHipster 8.x teams, this isn’t a gentle bump - the new version is huge.

Release Notes

LibericaJDK 26

BellSoft shipped Liberica JDK 26. Of the total 2,825 fixes (2,665 OpenJDK + 160 JavaFX), BellSoft contributed 9. Business as usual from one of the more reliable OpenJDK distributors.

JobRunr 8.5.0

JobRunr 8.5.0 improves startup performance by replacing individual SQL migration queries with a single batch query - a change that sounds trivial but makes a real difference in environments with dozens of migrations stacking up on cold start. Also fixes an AccessControlException when calling ForkJoinPool.commonPool() with the deprecated SecurityManager - a classic “Java archaeology” bug that’s becoming increasingly common as the ecosystem moves away from Security Manager while legacy configurations linger.

Worth noting in the broader context: JobRunr is quietly becoming more than just a background job library - with ClawRunr built on top (see above), it’s positioning itself as foundational infrastructure for the JVM agentic stack.

I also working on some JobRunr based solution - I will share some details soon 🤞

Apache Solr 10

Apache Solr 10 is the first major release since the 9.x series - and this time the changes run deep. Under the hood sits Lucene 10.3, with the minimum raised to Java 21 (SolrJ still works on 17). The biggest story is, of course, vector search: Solr 10 introduces support for scalar and binary quantized dense vectors, significantly reducing memory usage and improving vector search performance. But the real bombshell is the cuVS-Lucene integration - a pluggable codec enabling GPU acceleration for vector operations using the CAGRA algorithm, designed specifically for massive GPU parallelism.

This is exactly the integration NVIDIA talked about at GTC (and JavaOne), citing a 6x end-to-end speedup for index building in Solr and 40x in Lucene itself - and the Java API for cuVS uses Project Panama (FFM API), which closes the loop with the rest of the JDK 21+ ecosystem.

3. GitHub All-Stars

Floci - Native AWS Emulation for Java Testing

Floci is a lightweight, open-source alternative to LocalStack, specifically optimized for Java ecosystems. Unlike containerized emulators, Floci is natively compiled — drastically reducing memory overhead and eliminating JVM warmup times in ephemeral CI/CD environments. Currently supports S3, SQS, and DynamoDB, with seamless Spring Boot, Quarkus, and Micronaut integration. The community is particularly interested in potential Quarkus DevService integration.

For JVM developers tired of LocalStack’s resource demands: “instant-on” readiness without the container overhead.

Savant - Explicit Target Control Over Plugin Magic

Savant is a new Java build system that takes a contrarian stance: no plugin-injected build targets. Plugins function as simple objects in a Groovy DSL - you call java.compile() directly instead of relying on hidden lifecycle side effects.

Despite the focus on transparency and JDK 17+ compatibility, the community response has been skeptical: documentation inconsistencies (C# examples in a Java build tool?), and the question of why not use Mill, Amper, or bld instead. The manual configuration burden may be prohibitively high.

Worth watching, but approach with caution.

KAP - Kotlin Applicative Parallelism

KAP applies Haskell’s Applicative Functor pattern to Kotlin Coroutines - a library for declaratively expressing parallel-then-sequential orchestration. The code shape is the dependency graph: applicative phases run in parallel, monadic phases wait for context. Comes with timeoutRace, retry with Schedule, circuit breakers, and Arrow integration. 906 tests, 119 JMH benchmarks, Kotlin Multiplatform support.

You don’t need to know Haskell to use it - but if you do, you’ll feel right at home.

Jar-Analyzer - Bytecode Analysis Engine

Jar-Analyzer is a bytecode analysis and visualization tool for Java archives. Useful for security auditing, dependency analysis, and understanding complex class hierarchies in third-party JARs. If you’ve ever wanted to look inside a JAR beyond what javap gives you -this is your tool.

PS: This is Asian software - do not expect letters everywehere. Maybe some LLM would be able to do the port/translation.

JavaDesugarer9To8 - Backporting Modern Java

JavaDesugarer9To8 does exactly what the name says: transforms Java 9+ bytecode back to Java 8 compatible bytecode. Niche, but useful for teams stuck on Java 8 runtimes that want to use libraries compiled against newer JDKs. The Android ecosystem has been doing this for years - nice to see it available for server-side use cases too.

However, I recommend to use that with cautious 😊

PS: The full KotlinConf’26 schedule is live - time to start planning! @Jake Wharton on “Talking to Terminals,” Josh Long on “Bootiful Kotlin,” and a talk on enterprise-ready AI agents with Koog from JetBrains. I’ll be there as a media partner - come say hi if you’re attending!

PS2: Yet another picture from “JVM Weekly in strange places” family: Polish classic mountain cottage

Let’s be honest - if JDK 26 had dropped on a quiet Tuesday without JavaOne in the background, we’d mostly be talking about HTTP/3 and the fact that Applets are finally gone (RIP, nobody’s crying). It’s a solid but not exactly revolutionary release — ten JEPs, half of which are yet another round of previews. But JavaOne 2026 is a completely different story. Java Verified Portfolio, Project Detroit back from the dead, Helidon moving to OpenJDK, Koog for Java from JetBrains... suddenly it turns out this isn’t the week of JDK 26 - it’s the week the Java ecosystem officially went all-in on AI and agents. And that’s genuinely interesting.

So today we’re doing a two-for-one - first we’ll walk through JDK 26 JEP by JEP and things other than just JEP’s (because there’s still plenty to discuss), and then we’ll get to what actually set the internet on fire this week. Let’s go.

1. JDK 26 Released!

Unlike JDK 25, which came with a massive 24 JEPs (including a significant LTS release milestone), JDK 26 is a much smaller release with only 10 JEPs. However, don’t let the smaller number fool you - this release brings some genuinely interesting changes, including the long-awaited HTTP/3 support and significant GC improvements.

Now, let’s go through the complete list of changes in the new edition.

Exegi monumentum - Stable Feature

JEP 517: HTTP/3 for the HTTP Client API

JEP 517 finally brings HTTP/3 support to the Java Platform (at least natively). The HTTP Client API (introduced in JDK 11) is updated to support the HTTP/3 protocol, which uses QUIC transport instead of TCP.

Why HTTP/3 matters: HTTP/3 offers potentially faster handshakes, avoidance of head-of-line blocking, and more reliable transport especially in environments with high packet loss. It’s already supported by most browsers and deployed on about a third of all websites.

Usage: HTTP/3 is opt-in. You can enable it per-client or per-request:

var client = HttpClient.newBuilder()
                       .version(HttpClient.Version.HTTP_3)
                       .build();

Or you can enable HTTP/3 for a specific request:

var request = HttpRequest.newBuilder(URI.create("https://example.com/"))
                         .version(HttpClient.Version.HTTP_3)
                         .GET().build();

The implementation transparently downgrades to HTTP/2 or HTTP/1.1 if the target server doesn’t support HTTP/3. Various discovery modes are available to control this behavior via the H3_DISCOVERY request option.

Goodbye, Old Friends - Removals and Preparations

JEP 504: Remove the Applet API

Probably the second biggest announcement this week. JEP 504 finally removes the Applet API from the Java Platform. This has been a long time coming – the API was deprecated in JDK 9 (2017), deprecated for removal in JDK 17 (2021), and now, with the Security Manager permanently disabled in JDK 24, there’s simply no reason to keep this obsolete code around.

What gets removed: The entire java.applet package (Applet, AppletContext, AppletStub, AudioClip), java.beans.AppletInitializer, javax.swing.JApplet, and any API elements that reference these classes.

Web browsers haven’t supported applets for years, and there hasn’t been a way to run applets using the JDK since the appletviewer tool was removed in JDK 11. It’s time to say goodbye to this relic of Java’s early web days.

Does anybody miss the old guy?

JEP 500: Prepare to Make Final Mean Final

JEP 500 begins the process of enforcing the integrity of final fields. Currently, the deep reflection API (setAccessible and set methods of java.lang.reflect.Field) allows final fields to be mutated at will – making the final keyword essentially meaningless from a runtime perspective.

The problem: Final fields represent immutable state, crucial for reasoning about correctness and enabling JVM optimizations like constant folding. But the ability to mutate them via reflection undermines all of this.

The solution: In JDK 26, mutating final fields via deep reflection will issue warnings by default. A future release will throw exceptions instead. Developers can opt in to final field mutation using --enable-final-field-mutation=MODULE_NAME when necessary.

Serialization libraries should migrate to using sun.reflect.ReflectionFactory, which provides a supported way to deserialize objects with final fields without requiring the --enable-final-field-mutation flag.

Performance - VM Internals

JEP 516: Ahead-of-Time Object Caching with Any GC

JEP 516 enhances the AOT cache (introduced in JEP 483) so that it can be used with any garbage collector, including ZGC. This is a significant improvement for Project Leyden’s startup optimization efforts.

The problem: Previously, cached Java objects were stored in a GC-specific format, making the AOT cache incompatible with ZGC. This forced users to choose between low-latency garbage collection OR fast startup - but not both.

The solution: Objects can now be cached in a GC-agnostic format using logical indices instead of memory addresses. When the cache is loaded, a background thread materializes objects one by one, converting indices to actual addresses appropriate for the current GC.

The JDK now includes two baseline AOT caches – one GC-agnostic and one GC-specific – and automatically selects the appropriate one based on the environment.

JEP 522: G1 GC: Improve Throughput by Reducing Synchronization

This time, a bit more theory needed.

G1 needs to know which parts of the Java heap were modified by the application so it can perform garbage collection safely. To do this, the heap is divided into small chunks called cards, and G1 maintains a card table—a simple structure that records which cards have been changed. Every time your code updates an object reference, the corresponding card is marked.

Before JEP 522, both application threads and garbage-collection threads updated the same card table. Because many threads were touching this shared structure, G1 had to use synchronization. Under heavy load, this locking became a bottleneck and reduced overall throughput.

JEP 522 changes this by introducing a second card table. Application threads now update one card table without any locking, using much simpler and faster write-barrier code. At the same time, GC threads work on the other card table. When G1 needs to hand work from the application to the GC, it simply swaps the two tables atomically.

This matters because updating object references is one of the most frequent operations in Java programs. Making this path cheaper improves performance across the board, especially for highly concurrent applications.

In practice, this results in a 5–15% throughput improvement for applications that heavily modify object references, and up to 5% improvement even for others. The write-barrier code was reduced from around 50 CPU instructions to about 12 on x64 systems. The extra memory cost is small - about 2 MB per 1 GB of heap - and is largely offset by memory optimizations introduced in recent JDK releases.

Nihil Novi Sub Sole - Preview Features Continue

JEP 526: Lazy Constants (Second Preview)

The goal of LazyConstant is to compute a value exactly once, in a thread-safe way, but only when it’s first accessed, not at class-initialization time. At the same time, it is designed so that once the value is initialized, the JVM can treat it like a constant and apply constant-folding and inlining optimizations, avoiding repeated reads or synchronization overhead.

In short: LazyConstant combines lazy initialization, safe concurrency, and JIT-level performance close to real constants. JEP 526 re-previews the API for deferred immutability, now renamed from StableValue to LazyConstant. The API has been significantly simplified to focus on high-level use cases.

Key changes from JDK 25:

• Renamed from StableValue to LazyConstant

• Removed low-level methods (orElseSet, setOrThrow, trySet)

• Factory methods for lazy lists and maps moved to List.ofLazy() and Map.ofLazy()

• null is no longer allowed as a computed value

private final LazyConstant<Logger> logger
    = LazyConstant.of(() -> Logger.create(OrderController.class));
void submitOrder() {
    logger.get().info("order started");  // Initialized on first access
}

JEP 525: Structured Concurrency (Sixth Preview)

Structured Concurrency API treats groups of related tasks running in different threads as single units of work, streamlining error handling and cancellation. JEP 525 continues the preview of the Structured Concurrency API with minor refinements.

Changes in this new preview:

• New Joiner.onTimeout() method for handling timeout expiration

• allSuccessfulOrThrow() now returns List<T> instead of Stream<Subtask<T>>

• anySuccessfulResultOrThrow() renamed to anySuccessfulOrThrow()

• Static open method now takes UnaryOperator instead of Function

Response handle() throws InterruptedException {
    try (var scope = StructuredTaskScope.open()) {
        Subtask<String> user = scope.fork(() -> findUser());
        Subtask<Integer> order = scope.fork(() -> fetchOrder());
        scope.join();
        return new Response(user.get(), order.get());
    }
}

JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)

PEM encoding/decoding API provides a concise way to convert between PEM text and cryptographic objects like keys, certificates, and certificate revocation list. JEP 524 continues the preview of it with several refinements.

Changes:

• PEMRecord is now named PEM and includes a decode() method

• EncryptedPrivateKeyInfo gets new encrypt() and getKeyPair() methods

• PEMEncoder and PEMDecoder now support KeyPair and PKCS8EncodedKeySpec encryption/decryption

String pem = PEMEncoder.of().encodeToString(privateKey);

PrivateKey key = PEMDecoder.of().decode(pem, PrivateKey.class);

JEP 530: Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

The feature enables uniform (finally!) data usage with type patterns for all types, whether primitive or reference, and allows switch to process values of any primitive type including boolean, float, double, and long. JEP 530 previews for the fourth time the extension of pattern matching to primitive types... so you probably know the drill 😉

Changes in this preview: Enhanced definition of unconditional exactness and tighter dominance checks in switch constructs. These changes enable the compiler to identify a wider range of coding errors, although some previously legal switch constructs will now be rejected.

// Primitive type patterns in switch

switch (x.getYearlyFlights()) {
    case 0 -> "No flights";
    case 1 -> "One flight";
    case int i when i >= 100 -> "Gold status!";
    case int i -> "Regular: " + i + " flights";
}

// instanceof with primitives - safe conversion check

int i = 1000;

if (i instanceof byte b) {
    // Only enters if i fits in a byte

}

JEP 529: Vector API (Eleventh Incubator)

The API legend (or rather myth) allowing to express vector computations that compile to optimal SIMD instructions on supported CPUs. JEP 529 continues the incubation of the Vector API without substantial changes. As a reminder - the Vector API will remain in incubation until necessary features from Project Valhalla (value classes) become available as preview features. At that point, it will be adapted to use them and promoted to preview status.

And with that, a small comment at the end... I honestly expected to see more Valhalla here by JDK 26, but we still don’t have it.

So it looks like we’ll probably have to wait a bit longer for the Vector API as well.

2. Beyond the JEPs - Notable Changes from Release Notes

While 10 JEPs make the headlines, JDK 26’s release notes contain a handful of smaller changes that are worth highlighting - some practical, some symbolic, and one that the internet will absolutely love.

Javadoc Dark Mode

Yes, you read that right. The API documentation generated by Javadoc now ships with a dark theme. You can toggle between light, dark, and system-default using the new theme button in the navigation bar. Is it a game-changer? No. Will it make your 2 AM debugging sessions marginally less painful? Absolutely.

Thread.stop() Is Finally Gone

In a poetic parallel to the Applet API removal (JEP 504), Java 26 also removes Thread.stop() - over 27 years after it was first marked as deprecated. That’s not a typo. The method was deprecated back in JDK 1.2, which shipped in December 1998. For context, Google was founded that same year.

There’s no JEP for this one - it’s tracked in the bug tracker under JDK-8368226. Together with the Applet API, JDK 26 is having a real “spring cleaning” moment.

JDBC 4.5

JDK 26 includes support for the JDBC 4.5 Maintenance Release. The headline change: Array, Blob, Clob, NClob, and SQLXML interfaces now extend AutoCloseable, with a default close() implementation that delegates to free(). This means you can finally use them in try-with-resources blocks without wrapping.

The release also adds default implementations of the quoted identifier methods (previously on Statement since JDK 9) to the Connection interface. A heads-up: if your JDBC driver has private or protected implementations of these newly-added default methods, you may hit compatibility issues. But I hope you do not have your own JDBC driver... unless you are in very interesting place 😁

UUID v7 Support

A new factory method java.util.UUID.ofEpochMillis(long) has been added, allowing creation of Type 7 UUIDs from a Unix epoch timestamp. Type 7 UUIDs are time-ordered and database-friendly - if you’ve been reaching for external libraries for this, you can stop now.

GC CPU Time Tracking

A new getTotalGcCpuTime() method on java.lang.management.MemoryMXBean returns the accumulated CPU time in nanoseconds for GC-related activity. Combined with the new -Xlog:cpu output that now prints a full breakdown table of VM CPU usage at exit, this gives you much better observability into where your JVM’s CPU cycles are actually going.

HPKE and Post-Quantum Ready JAR Signing

Two non-JEP security additions that Oracle is highlighting prominently: Java 26 ships with Hybrid Public Key Encryption (HPKE) out of the box, and introduces post-quantum ready JAR signing. The HPKE support is interesting on its own, but it’s the JAR signing part that has longer-term implications for supply chain security — especially with JEP 527 (Post-Quantum Hybrid Key Exchange for TLS 1.3) already targeted for JDK 27. Oracle is clearly building out the post-quantum story piece by piece.

Virtual Threads: Unmounting During Class Initialization

A small but significant Loom improvement: virtual threads now unmount from the carrier thread when waiting for another thread to execute a class initializer. Previously, this was one of the remaining scenarios where a virtual thread would pin its carrier — making the platform thread unavailable for other work. If you’ve been tracking the gradual elimination of pinning scenarios since JDK 21, this is another step in the right direction.

3. JavaOne 2026 Announcements

JDK 26’s release day coincides with JavaOne 2026 (March 17–19, Redwood Shores, CA), and Oracle used the occasion to make several ecosystem announcements that arguably overshadow the JDK release itself.

Here, you will find the Keynote and... it was a loaded one - and the title says everything.

Here you will find the most important non-directly-JDK related announcements.

Java Verified Portfolio (JVP)

The biggest announcement is the introduction of the Java Verified Portfolio - a curated, Oracle-supported collection of tools, frameworks, libraries, and services that extends enterprise support beyond the JDK itself.

At launch, JVP includes:

• Helidon - Oracle’s open-source, cloud-native microservices framework built on Virtual Threads, with LangChain4j integration and MCP-based AI agent support

• JavaFX - reintroduced under commercial support after a multi-year gap, driven by demand for rich interactive UIs in AI analytics and data visualization

• Java Platform Extension for VS Code

JVP is included at no additional cost for Java SE subscribers and OCI customers. Oracle is clearly positioning this as a supply-chain risk reduction play — instead of tracking multiple upstream sources with varying support timelines, you get a single, Oracle-governed source of truth with roadmap alignment to JDK releases.

Project Detroit - Java and JavaScript/Python Interop

While JVP was the most important, this one is the most forward-looking announcement: Oracle introduced Project Detroit, designed to enable fast, seamless interoperability between Java, JavaScript, and Python.

If the name sounds familiar, that’s because it’s a resurrection. The original Detroit project was created in February 2018 as a bridge between Java and JavaScript via V8, but it never got off the ground and was dissolved in September 2024. In February 2026, Sundararajan Athijegannathan (who offered to lead the project) proposed its recreation, noting that “with the rise of AI, there is also interest in accessing AI functionality written in Python from Java applications.”

The approach is fundamentally different from what we had with Nashorn or GraalVM’s Truffle-based language implementations. As Bernard Traversat (VP Software Development at Oracle) explained at the JavaOne briefing: instead of reimplementing JavaScript or Python on top of the JVM - where you’re constantly “swimming against the current” chasing language spec corner cases - Detroit embeds the V8 and CPython runtimes directly inside the JVM process via the FFM API. This gives you native compatibility for free and clear heap isolation between Java and the guest language.

The irony here is hard to miss. Oracle JDK 24 was the last release to include the experimental Graal JIT compiler, and GraalVM for JDK 24 was the last version licensed under Java SE - effectively detaching GraalVM’s polyglot story from the JDK ecosystem train. And now, barely a year and a half later, Oracle is rebuilding the polyglot interop capability from scratch, this time with a radically simpler architecture - to be fair, Detroit’s approach is architecturally quite different from Truffle.

The project team includes some serious OpenJDK heavyweights (Jim Laskey, Maurizio Cimadamore, Alan Bateman, among others), and the CFV (Call for Votes) passed on the OpenJDK announce list in March. Oracle is now officially proposing it as an OpenJDK project with repos already up on GitHub (detroit, detroit-python).

Helidon → OpenJDK

Oracle is contributing Helidon to OpenJDK and aligning its release cadence with the JDK - meaning Helidon will ship alongside each JDK release and share LTS timelines. This is a notable move: it elevates Helidon from “Oracle’s microservices framework” to a community-governed project with first-class JDK integration.

Waiting for additional details here! As soon I have them, I’ll share 😊

JetBrains Announces Koog for Java

Not all JavaOne news came from Oracle. JetBrains chose the conference to announce Koog for Java - bringing their AI agent framework, originally built in Kotlin, to idiomatic Java with fluent builder-style APIs.

Koog is an open-source framework for building enterprise-ready AI agents on the JVM. What makes it interesting is that it’s not a research project - JetBrains built it to power their own AI features in IntelliJ and other products, then extracted it as a standalone framework. The feature set reads like a wishlist for anyone who’s tried to build reliable agents: graph-based workflow strategies, persistent checkpointing (resume from exactly where you stopped after a crash), intelligent history compression for long-running conversations, Spring Boot integration, MCP support, and observability via OpenTelemetry exporters to Langfuse and W&B Weave.

The Java API launch is particularly well-timed. With Oracle pushing the “Java for AI” narrative hard (see below), and Rod Johnson’s Embabel taking a Spring-native, domain-modeling approach to the same problem space, we’re suddenly seeing a real competition for the JVM agent framework crown. As a recent comparison piece put it: Embabel reasons about goals and conditions (think: declarative planning), while Koog asks you to define a directed graph of nodes (think: LangGraph, but on the JVM). Different philosophies, same goal - making Python optional for the agent layer of your stack.

BTW: Java 26 is already available in IntelliJ IDEA.

The AI Narrative

The keynote’s title alone - “Java for an AI World” - tells you everything about where Oracle’s head is at right now.

Ana-Maria Mihalceanu and Lize Raes - both Oracle Developer Advocates - had a remarkably long segment during the keynote. Together with Paul Sandoz, they covered two angles: the Babylon/HAT stack (from JDK building blocks through GPU-enabled libraries to Java code running on GPUs), and a practical demo of an LLM-powered triage system for a medical appointment helpdesk - automatic ticket classification, urgency flagging, matching against known bugs with relevance scores, and a clear split between what AI handles and where humans stay in control.

The amount of keynote time Oracle gave to these topics says more than any roadmap slide.

Who outside of Oracle team was on the JavaOne Stage

The opening keynote - wasn’t just an Oracle show. Rod Johnson, Josh Long, and engineering leads from Microsoft, NVIDIA, and Uber all shared the stage. That lineup alone tells you something about where the Java ecosystem is headed.

Microsoft came with a concrete developer play: the GitHub Copilot Community SDK for Java, which brings programmatic control of Copilot CLI and its agents into the Java ecosystem — including conversational AI sessions, custom tools, streaming events, and MCP server integration. Their sessions covered building production GenAI systems with LangChain4j and vector search on Azure. Oh, and mark your calendars: Microsoft also invited evereyone to JDConf 2026 (April 8–9), their free virtual Java developer conference, now in its sixth year.

NVIDIA and Ikroop Dhillon had a presence that reflects Java’s growing role in GPU-accelerated workloads. With GTC 2026 running concurrently (literally across town in San Jose), the Java-NVIDIA intersection is Project Babylon territory - extending Java’s reach into AI model training and GPU compute. The broader theme: Java as the orchestration layer for inference pipelines that run on NVIDIA hardware. However, while it was interesting, it was more about Nvidia than Java, with an Apache Solr guest appearing.

Uber presented probably the most hands-on production story at the conference: how they scaled GPU-accelerated inference while maintaining strict tail-latency SLOs in a JVM-centric environment. Their talk covered how Java services integrate with NVIDIA Triton Inference Server to serve models from small neural nets to multi-hundred-gigabyte LLMs, and the JVM tuning rabbit holes that followed. If you want proof that “Java for AI” isn’t just marketing, this is it.

Josh Long , in his trademark style, took the stage to show just how quickly you can go from zero to a working AI-integrated application with Spring Boot 4.0.3 and Spring AI. Starting from Spring Initializr he demoed the new capabilities of the Spring ecosystem, building an app on the spot. He also showed off the OpenAI integration and PassKeys support in Spring Security via a pre-recorded demo — the keynote pace was so relentless that even Josh Long couldn’t live-code everything. And because it’s Josh Long, the whole thing came with Hitchhiker’s Guide to the Galaxy references, because of course it did.

42.

PS: Valhalla Update: Early Access 3 Is Here

On the Valhalla front, things are moving faster than it might seem from the JDK 26 JEP list alone. While JDK 26 ships without any Valhalla features (and the Vector API remains in incubation waiting for them), the Valhalla team has been busy outside the main release train. Just last week, Build 27-jep401ea3+1-1 - the third Early Access build of JEP 401: Value Classes and Objects - was made available, based on an incomplete version of JDK 27.

This is the third EA milestone since the first build dropped in October 2025, and the pace of iteration suggests that JEP 401 is getting closer to targeting a release. The EA build focuses on two key optimizations: heap flattening (reducing the memory footprint of value objects in fields and arrays) and scalarization (avoiding memory allocation in JIT-compiled code). In benchmarks, the results are already impressive - Dan Smith’s original demo showed significant performance improvements for arrays of value objects compared to identity objects.

And a shout-out to the DataLinks crew who are on the ground at JavaOne! Thanks to Michal Niczyporuk for the photo - great to have Polish representation in Redwood Shores.

It was supposed to be a quiet week. JavaOne is next week, JDK 26 is looming, and I already had that prepared for vol. 167. But JetBrains apparently didn’t get the memo about pacing, because they dropped two product launches on a Sunday.

Let me get the biggest thing out of the way first: announced product, Jetbrains Air, is not an IDE in a classic sense. JetBrains is calling it an “Agentic Development Environment” - an ADE, if you will - and the distinction actually matters. Where an IDE adds tools to a code editor, Air builds tools around the agent. Your job isn’t to write code; it’s to define tasks, supervise agents, and review their output. If that sounds like a philosophical shift, that’s because it is.

Air launched on March 9th as a public preview, and it supports Codex, Claude Agent, Gemini CLI, and Junie out of the box. It’s built on the Agent Client Protocol (ACP), the open standard JetBrains has been co-developing with Zed since last year (with an ACP Registry already live since January). The idea is simple: implement ACP once, and your agent works in Zed, JetBrains IDEs, Neovim, and anywhere else the protocol reaches. Think LSP, but for AI agents.

The key concept in Air is a task - you describe what you want done, optionally mentioning specific lines, commits, classes or methods for precise context, and an agent goes off to work on it. You can run multiple agents on different tasks concurrently, each isolated in its own Git worktree or Docker container. When an agent finishes, you review the changes not just as a diff, but in the context of your entire codebase, with a terminal, Git client, and built-in preview right there.

Now, here’s the part that will raise eyebrows for some: Air is built on the Fleet codebase. Yes, that Fleet - the one JetBrains discontinued in December 2025 after four years in preview without ever reaching GA. The architecture is modern (closer to VS Code than IntelliJ in terms of performance), but some of Fleet’s ghosts linger - early users are already reporting the familiar memory footprint issues, and the whole thing is macOS-only for now, with Windows and Linux promised for later.

For the business model: if you have a JetBrains AI Pro or AI Ultimate subscription (included in the All Products Pack), all agents are included. Otherwise, it’s BYOK - bring your own API keys from Anthropic, OpenAI, or Google. Cloud execution (agents running in remote sandboxes) is in tech preview and coming soon.

The strategic positioning is clear. JetBrains is looking at Cursor, Warp Oz, AWS Kiro, Google Antigravity, and the whole wave of AI-native tools and saying: “We’ve been building developer tools for 26 years - we can do this too, but our way.” Whether that’s a strength or a liability depends on whom you ask.

As The Register noted, JetBrains will have a difficult time balancing the needs of their loyal IntelliJ customers - who absolutely do not want to switch to a different product - while trying to establish a new AI-centric environment.

Alongside Air, JetBrains also released Junie CLI in beta - essentially making their coding agent a standalone tool that works from the terminal, inside any IDE, in CI/CD pipelines, and on GitHub/GitLab. It’s LLM-agnostic (supporting models from OpenAI, Anthropic, Google, and Grok), open-source on GitHub, and ships with a BYOK pricing model. There’s even a free week of Gemini 3 Flash to get you started.

The feature list reads well: one-click migration from Claude Code or Codex, custom subagents, Agent Skills for domain-specific rules, project-level guidelines via .junie/guidelines.md, and a GitHub Action for automated PR handling. Junie CLI positions itself as the “coding buddy” that goes wherever you work.

But here’s the elephant in the room that the community has been pointing out for a while now: JetBrains’ AI product lineup is getting confusing. You’ve got the AI Assistant (the in-IDE chat), Junie (the agent, now in both IDE plugin and CLI forms), Mellum (JetBrains’ own LLM), and now Air (the ADE). As 👋 julien lengrand-lambert 👋 in a bit old, but still valid longer experience post put it well - it feels like learning a bunch of new product names with little differentiation. The pricing page says you kind of get everything with a subscription, but the “when should I use what” story needs serious work.

On the positive side, Junie’s deep integration with JetBrains’ static analysis engine is a genuine differentiator. As one Hacker News commenter noted, an agent with access to the IDE’s own analysis database - navigate into functions, check API docs, validate code without full compilation - has massive potential compared to agents that can only grep and hope.

The biggest open question from the community: will JetBrains support local models (Ollama, Qwen, etc.)? The official answer for now is “no ETA, but it’s an active topic.” For enterprise customers with data sensitivity concerns, this might be a dealbreaker and very nice competitor to Open Code.

And since we’re on the topic of Junie CLI, let me sneak in a personal story that ties rather nicely to the whole “agents are changing developer workflows” narrative. Because last month I went down a rabbit hole that started with “I want to run Claude Code from my iPhone” and ended... somewhere else entirely.

Here’s the context. The fire-and-forget pattern of agentic coding - give an AI a task, let it work, check in periodically - fundamentally changes what you need from a terminal. You don’t need to write code on your phone. You need to supervise it. Peek at progress while your daughter refuses to fall asleep unless you’re sitting next to her bed (yes, my five-year-old has strong opinions about bedtime protocol 🤷). Confirm a decision from a train somewhere around Miechów. Glance at a build from the couch. That kind of thing.

So I built a stack: Tailscale for mesh VPN (every device gets a private 100.x.x.x IP, zero port forwarding, just works - if more technology was this invisible, half of DevOps would need new hobbies), Mosh (Mobile Shell from MIT) instead of SSH for connection resilience (UDP-based, survives network switches, local echo for instant keystroke feedback - research shows 0.33s response at 29% packet loss vs 16.8s for SSH, which is a 50x difference), tmux for persistent sessions, and Terminus on iOS as the client.

Beautiful theory. Then I launched Claude Code inside that stack and the screen turned into the Matrix after a panic attack.

The issue is fundamental: Claude Code’s TUI uses complex ANSI escape sequences - syntax coloring, box drawing, spinner animations, multi-region screen updates. Mosh synchronizes snapshots of visible terminal state, not the full byte stream. These two approaches simply don’t get along. I tried everything - Ctrl+l redraws (temporary fix), --output-format stream-json (works but you lose the TUI), tmux with screen-256color and escape-time 10 (marginal improvement). Pure SSH fixes the rendering but kills the connection resilience - which was the whole point.

And here’s where the plot twist happens that anyone who’s worked with technology knows well: sometimes it’s better to change the problem than to keep looking for a solution.

Junie CLI has a much simpler terminal interface. Less ANSI fanfare, less UI complexity - but what you need, works. Through Mosh, through tmux, from a phone. No artifacts, no garbled screens. The final workflow: ssh from phone triggers an auto-attach script that detects existing junie-* sessions, shows a picker menu, and either joins an existing session or creates a new one with a timestamp name. Detach with Ctrl+b d, close the laptop, attach an hour later from the phone - agent’s still working, output waiting in the session. Exactly the fire-and-forget I was after.

Is it an optimal setup? Probably not. Does it work? Yes. And in our industry, that’s sometimes the only metric that counts. And you do not need to pay for Claude Code Max 😁

(PS within a PS: The whole adventure of debugging Mosh + Claude Code took longer than the actual coding I wanted to do from my phone. Classic developer move — spending hours automating something you could do manually in five minutes. But at least I have notes for next time. And an article.)

Let’s shift gears entirely. While the AI tooling world is busy arguing about which agent is better at writing your code, there’s a project that’s been quietly enabling Java to run on the hardware that powers all those AI models. TornadoVM 3.0 landed in late February, and while it’s not a flashy launch, it’s a significant milestone for an important project.

For those not yet familiar (and I realize I’ve been writing about TornadoVM in this newsletter since... well, a while), here’s the pitch: TornadoVM is a plugin for OpenJDK that allows Java programs to be automatically offloaded to GPUs, FPGAs, and multi-core CPUs. It compiles Java bytecode at runtime - acting as a JIT compiler - to one of three backends: OpenCL C, NVIDIA CUDA PTX, and SPIR-V. The project comes from the Beehive Lab at the University of Manchester, and it supports hardware from NVIDIA, Intel, AMD, ARM, and even RISC-V.

The 3.0 release itself is primarily a maintenance milestone - bug fixes, dependency upgrades, a refactor of IntelliJ project generation, and a split of JDK 21/JDK 25 testing pipelines. Not headline material on its own. But what makes TornadoVM worth watching right now is the trajectory, not just the release.

Consider what’s been happening: version 2.0 (December 2025) brought GPU-native INT8 types for PTX and OpenCL, zero-copy native array types, FP32 to FP16 conversion across all backends, and (crucially) GPULlama3.java - a Java-native implementation of Llama 3 inference that compiles and runs on GPUs. Version 2.2 shipped just weeks later with further optimizations. And on the roadmap, there’s an open issue for CUDA Graphs support - which would allow TornadoVM’s TaskGraphs to be captured and replayed with minimal CPU overhead, a natural fit for iterative workloads like ML inference and physics simulations.

The reason I’m filing TornadoVM under “loosely related to AI” is that the project sits at a fascinating intersection. Java enterprises - banks, insurers, logistics companies - have decades of investment in the JVM. AI inference requires GPU compute. Today, that usually means crossing a language boundary to Python or C++. TornadoVM (along with Project Babylon/HAT, which I’ll write more about when JDK 26 drops) sketches a path where Java applications can stay in Java all the way down to the GPU kernel.

TornadoVM offers two APIs for expressing parallelism: a Loop Parallel API using @Parallel and @Reduce annotations (ideal for non-GPU-experts), and a Kernel API via KernelContext that gives you explicit thread IDs, local memory, and barriers - essentially CUDA/OpenCL-style programming in pure Java. Both can be combined in a single TaskGraph. It’s not going to replace PyTorch or CUDA in raw performance benchmarks any time soon, but for Java shops that want to offload compute-intensive workloads to GPU hardware without learning a new language stack, there’s genuinely nothing else like it in the ecosystem.

And yes, this is related to the AI tooling story. Because if we’re going to have a conversation about “Java in the age of AI”, it’s not just about which agent writes your Java code fastest. It’s about whether Java can be the language that runs the AI workload too. TornadoVM is one of the strongest arguments that it can.

PS: Next week is JavaOne, and I’ve already reserved vol. 167 for JDK 26 coverage - there’s going to be a lot to unpack.

Year ago I announced that JVM Weekly had joined the Friends of OpenJDK (Foojay.io) family. Foojay.io is a dynamic, community-driven platform for OpenJDK users, primarily Java and Kotlin enthusiasts. As a hub for the “Friends of OpenJDK,” Foojay.io gathers a rich collection of articles written by industry experts and active community members, offering valuable insights into the latest trends, tools, and practices within the OpenJDK ecosystem.

This month’s main feature is a piece that is a follow up to what I was already men. Bruno Borges from the Developer Relations team at Microsoft/GitHub published a fantastic writeup on Foojay about how he internationalized his java.evolved website - 112 patterns across 11 categories - into 9 languages in a single night.

Translating a Website into 8 Languages with AI Agents in One Night

How I used Claude Sonnet 4.6 and fleets of GitHub Copilot Coding Agents to internationalize java.evolved - from spec to deployment

java.evolved is a static site I built to showcase modern Java patterns side-by-side with their legacy equivalents. 112 patterns across 11 categories -- language, collections, streams, concurrency, and more - each with code comparisons, explanations, and curated documentation links. All generated from YAML content files by a JBang-powered Java build script.

By the end of February 25, the entire site was English-only. By the morning of February 26, it was available in 9 languages - English, German, Spanish, Portuguese (Brazil), Simplified Chinese, Arabic, French, Japanese, and Korean -- with full RTL support for Arabic. The total human effort was a few hours of prompting, reviewing PRs, and filing one bug.

This is the story of that experiment.

The Architecture Decision: Let the AI Draft the Spec

The first step wasn’t writing code. It was writing a specification.

I opened issue #74 - “Plan architectural change for i18n” - and assigned it to a Copilot Coding Agent. The prompt was simple: propose an architectural plan for internationalizing the website, considering the existing static-site structure.

The agent (PR #75) came back with a comprehensive i18n specification that addressed:

• Two-layer translation model: UI strings (labels, nav, footer) separated from content translations (pattern titles, explanations, summaries)

• Partial translation files: Translation files contain only translatable fields. Structural data (code snippets, navigation links, metadata) always comes from the English source of truth

• Graceful fallback: Missing translations fall back to English with a build-time warning -- no page is ever blank

• Locale registry: A simple locales.properties file drives the entire build pipeline and language selector

• AI-friendly design: The architecture was explicitly designed so that an AI receives the full English content and returns a partial translation file -- no field-filtering logic needed in the prompt

This last point proved prescient. The clean separation between “what changes per locale” and “what stays constant” meant each translation task was self-contained and parallelizable.

After iterating through review comments over 5 days (the original PR had 12 comments of back-and-forth), the spec was merged on February 25.

Phase 1: Building the Infrastructure

With the spec in hand, I coordinated an agent locally with Copilot CLI to implement the core i18n infrastructure in PR #83 - the generator changes that made everything locale-aware:

• The generate.java build script learned to iterate all locales from locales.properties

• Template tokens like {{sections.codeComparison}} replaced hard-coded English strings

• hreflang meta tags, a locale picker dropdown, and client-side locale detection were added

• The resolveSnippet function loads translated content overlaid onto the English base, falling back gracefully when a translation doesn’t exist

This was the only PR that required significant intervention. Everything after it was delegation.

Phase 2: The First Translations (Spanish + Portuguese)

The first real translation - Spanish - came in PR #84. This PR also migrated the English content files from JSON to YAML for improved readability -- a format change that the AI handled naturally since the generator already supported multiple formats.

Brazilian Portuguese followed immediately in PR #85, completing all 112 pattern files. These first two translations validated the architecture and surfaced a CI issue: the deploy workflow’s path triggers didn’t match YAML files or the translations/ directory. A quick fix in PR #86 resolved that.

Phase 3: The Fleet - 6 Languages in Parallel

This is where things got interesting. With the architecture proven and two complete translations validated, I launched a fleet of Copilot Coding Agents -- multiple agents working in parallel, each assigned a single language. I used the Copilot CLI /delegate command to dispatch them asynchronously, all with the same prompt:

Each agent independently:

1. Read the i18n spec and understood the file structure

2. Created a UI strings YAML file with 60+ translated keys

3. Generated 112 content translation YAML files -- one per pattern, across all 11 categories

4. Registered the locale in locales.properties

5. Opened a PR with a detailed description of what was translated

All six PRs were opened within a span of about 12 minutes (2:33 AM to 2:45 AM) and were all merged within the next hour. No translation conflicts, no merge issues, no structural errors.

The Numbers

By the time the fleet finished:

• 8 locales fully supported (besides English)

• 112 patterns x 8 translated locales = 896 content translation files

• 8 UI string files with 60+ keys each

• ~1,008 generated HTML pages (112 pages x 8 locales)

• 8 localized search indexes (snippets.json per locale)

The Arabic Surprise: RTL Support

The most impressive moment was the Arabic translation (PR #91). The agent not only translated, it also noted that Arabic is a right-to-left language and proactively added RTL infrastructure:

• Added dir="{{htmlDir}}" to the <html> tag in both templates

• Modified the generator to resolve htmlDir to "rtl" for Arabic and "ltr" for all other locales

• Updated the Python benchmark generator to pass the new token

This was a genuinely thoughtful architectural change that I hadn’t explicitly requested. The agent understood that Arabic support implies RTL layout and acted on it.

The One Bug

Of course, it wasn’t perfect. When dir="rtl" is applied globally, the browser flips everything -- including Java source code blocks and the navigation bar, which should always be LTR regardless of locale. I spotted this when reviewing the deployed site and filed issue #96.

A Copilot Coding Agent fixed it in PR #97 within minutes, adding targeted CSS overrides. Arabic prose continues to render RTL. Java code stays LTR. One bug, one issue, one PR, fixed in minutes.

[dir="rtl"] nav,
[dir="rtl"] .nav-inner {
  direction: ltr;
}

[dir="rtl"] pre,
[dir="rtl"] code,
[dir="rtl"] .code-text,
[dir="rtl"] .card-code,
[dir="rtl"] .compare-code {
  direction: ltr;
  text-align: left;
  unicode-bidi: embed;
}

Why It Worked: Architecture as Force Multiplier

This experiment succeeded because of deliberate architectural decisions, not just because of a magic AI prompt:

Source of Truth Separation -- Content files contain both translatable text and structural data. But translation files contain only the translatable fields. The generator overlays translations onto the English base at build time. AI agents can’t accidentally modify code snippets or break navigation.

Partial File Fallback -- If a pattern has no translation file for a locale, the site shows the English content with an “untranslated” banner. Partial translations are always valid. New patterns added in English are immediately visible in all locales.

Convention Over Configuration -- Each locale follows the same directory structure. Adding a new language is a checklist: add a line to locales.properties, create the strings file, create content files. No code changes needed in the generator.

Lessons Learned

What Went Well:

• Spec-first approach: Having the AI draft the specification before any implementation meant the architecture was explicitly designed for AI-driven translation from day one

• Fleet parallelism: Six language translations running simultaneously with zero conflicts demonstrates that well-isolated task boundaries enable effortless parallelization

• Proactive problem-solving: The Arabic agent identifying and implementing RTL support without being explicitly asked shows that LLMs can reason about downstream implications

• Technical term preservation: Across all 9 languages, Java API names, annotations, JDK versions, and code examples were correctly left in English

What Required Human Intervention:

• One bug: The RTL global flip affecting code blocks

• CI pipeline fixes: The deploy workflow needed path trigger updates

• Review and merge: Each PR needed a human to review and merge

The java.evolved project is open source at github.com/javaevolved/javaevolved.github.io. The i18n specification lives at specs/i18n/i18n-spec.md.

The Timeline

Conclusion

The experiment proved a simple thesis: if you design your architecture for AI-driven workflows, AI agents can do remarkable things.

I didn’t build a custom translation pipeline or prompt-engineering framework. I wrote a specification. An AI agent drafted it, I refined it through code review, and then a fleet of agents executed against it. The architecture - partial files, fallback behavior, source-of-truth separation - did all the heavy lifting.

The result is a Java patterns reference site available in 8 languages, with 1,008 generated pages, serving developers who speak English, German, Spanish, Portuguese, Chinese, Arabic, French, and Korean. It handles right-to-left layouts. It has localized search. Every page has proper hreflang tags for SEO.

And the only bug was a CSS rule that took 13 minutes from report to fix.

The future isn’t AI replacing developers. It’s developers designing systems that let AI do what it’s good at - repetitive, structured, parallelizable work - while humans focus on architecture, review, and the occasional RTL bug.

java.evolved is open source at github.com/javaevolved/javaevolved.github.io. The i18n specification lives at specs/i18n/i18n-spec.md.

My take: This article is a nice example of what I keep calling “engineering-first AI usage.” Bruno didn’t just throw prompts at a wall -- he made the AI draft an architecture that was explicitly designed for parallelized, agent-driven work. The spec-first approach, the partial-file design, the convention-over-configuration pattern - all of this is what separates “vibe coding” from what I’d call “vibe engineering.” The architecture is the prompt, in a sense.

What’s particularly interesting from the JVM perspective is that the entire build pipeline is powered by JBang - a single generate.java script that handles locale iteration, template resolution, and content overlay. No Maven, no Gradle, just JBang doing what it does best: making Java scripts feel as natural as shell scripts. Between this and the java.evolved project itself (which is a fantastic community resource for showcasing modern Java), Bruno keeps proving that Java’s developer experience has come a long way.

Also - 896 translation files, zero merge conflicts, in one night. The “fleet” pattern of dispatching multiple agents in parallel is something I expect we’ll see a lot more of.

Oh, and one more thing - inspired by Bruno’s work, I went ahead and did the Polish translation myself. It’s live at javaevolved.github.io/pl/. Poland Strong.

Also on Foojay This Month

Foojay Podcast #91: 25 Years of IntelliJ IDEA: The IDE That Grew Up With Java - Frank Delporte celebrates a quarter century of IntelliJ IDEA with guests from the JetBrains team - Marit van Dijk and Anton Arhipov. From the early days of revolutionary code completion to AI-powered features and the recent unified Community/Ultimate release - a great retrospective.

As someone deeply embedded in the JetBrains/Kotlin ecosystem (which probably surprises no one at this point), I always have a soft spot for the 'behind the scenes' stories - how IntelliJ evolved alongside Java itself. Highly recommend watching this one, as I've been following this story through pretty much my entire career, and I have to say, it's one of those tales that never gets old 😁

I Got Java 25 Running on the RISC-V BeagleBoard BeagleV-Fire

by Frank Delporte

Frank continues his 2026 single-board computer testing plan and successfully gets Java 25 running on RISC-V hardware. The key was updating the OS via BeagleBoard Imaging Utility (the BeagleV-Fire uses eMMC, not SD cards like Raspberry Pi). Once on Ubuntu 24, Java 25 installed via standard apt. Even SDKMAN and JBang work. Exciting times for Java on RISC-V - after experimenting with Arm last year, I need to play with this a bit.

Watch the Recording: DIY Technical Marketing for Java Developers

by Dominika Tasarz-Sochacka from Payara

A Jfokus 2026 talk about personal branding for developers. I was at the session and loved it. Great stuff! The core message - that small, intentional actions make a real difference for your career visibility without turning it into a full-time job - really resonated. Highly recommended for anyone who writes code for a living but hasn’t started writing about code yet.

Optimizing the MongoDB Java Driver: How Minor Optimizations Led to Macro Gains

by Nasir Qureshi and Slab Babanin

The MongoDB Java team shares how they achieved throughput improvements between 20% and over 90% in specific workloads. Techniques include JVM intrinsics, SWAR (SIMD Within A Register) for null-terminator detection in BSON, caching BSON array indexes, and eliminating redundant invariant checks. The guiding principle: “never guess, always measure.”

The largest improvement - +96.46% in Large doc Collection BulkWrite insert - is jaw-dropping. A truly excellent deep-dive into low-level Java performance.

Unikernel: Profiling and Troubleshooting JVM on Nanos Unikernel

by Angelo Rubini

Can you profile a Java application running inside a unikernel with standard JVM tools? The answer is yes. Angelo walks through profiling a Quarkus application on Nanos unikernel using JProfiler and IBM Semeru JRE 25 (OpenJ9).

No special hacks - just standard JVMTI agent loading. Unikernels continue to be one of the most underexplored deployment targets for Java, and this article does a lot to demystify the operational side.

Bringing Java Closer to Education: A Community-Driven Initiative

by Igor De Souza

A heartfelt piece about the Java Education Catalog on GitHub - a community-driven effort to gather, organize, and curate Java educational materials in one accessible place, especially for Raspberry Pi and physical computing contexts. The initiative grew out of conversations in the Code Club Slack, and Igor recently discussed it on Foojay Podcast #85. A wonderful example of community organizing that goes beyond code.

And it’s all, folks.

This time we have plenty of material: from a fascinating interview with Kotlin’s creator, through a groundbreaking change in Minecraft, to a whole wave of new projects proving that Java UI is in much better shape than anyone would expect. Let’s dive in!

1. February: The Rest of the Story

Gergely Orosz on his Pragmatic Engineer podcast conducted an extensive interview with Andrey Breslav, the creator of Kotlin and founder of CodeSpeak. The conversation is a goldmine of little-known facts about Kotlin’s history - for example, that the first version of Kotlin wasn’t a compiler but an IDE plugin, that the initial team consisted mainly of fresh graduates, or that smart casts were inspired by the obscure language Gosu.

But the most interesting thread concerns the future. Breslav is now building CodeSpeak - a new programming language designed to reduce boilerplate by replacing trivial code with concise natural language descriptions. The motivation? Keeping humans in control of the software development cycle in the age of LLM agents. As he put it - in the future, engineers will still be building complex systems, and it’s worth remembering that, even if Twitter is trying to convince us otherwise (heh).

Moderne announced that their OpenRewrite platform - known primarily in the Java ecosystem as a tool for automatic code refactoring - officially now supports Python. Python code can now be parsed, analyzed, and transformed alongside Java and JavaScript within the same Lossless Semantic Tree (LST).

Why does this matter for us JVM folks? Because modern systems rarely evolve in isolation. A Java service might expose an API consumed by a Python integration, a shared dependency might appear in backend services, frontend tooling, and automation scripts. With Python in the LST, dependency upgrades can be coordinated in a single campaign across multiple languages.

An interesting extension to the mission of one of the JVM ecosystem’s most important tools.

Igor Souza wrote a fun article celebrating the 40th anniversary of Legend of Zelda, comparing the triangle of performance improvements in Java 25 to the legendary Triforce. The analogy connects three key improvements: optimized class caching (AOT caching) for faster startup, Compact Object Headers for more efficient memory use, and garbage collection improvements. Java “Power, Wisdom, Courage” - genuinely a lovely connection with gaming lore.

Continuing the video games related topics, big news from the gamedev side of JVM - Mojang announced that Minecraft Java Edition is switching from OpenGL to Vulkan as part of the upcoming “Vibrant Visuals” update. This is a massive change for one of the most popular games written in Java. The goal is both visual improvements and better performance. Mojang confirmed that the game will still support macOS and Linux (on macOS through a translation layer, since Apple doesn’t natively support Vulkan).

Interestingly, this is probably the first Java game to use Vulkan. Modders should start preparing for the migration - moving away from OpenGL will require more effort than a typical update. Snapshots with Vulkan alongside OpenGL are expected “sometime in summer,” with the ability to switch between them until things stabilize.

PS: I started to introduce my daughter to Minecraft ❤️ Fun time.

JetBrains announced that starting from version 2026.1 EAP, IntelliJ-based IDEs will run natively on Wayland by default. This is a significant step, particularly since Wayland has become the default display server in most modern Linux distributions.

One small difference in practice - the startup splash screen won’t be displayed, because it can’t be reliably centered on Wayland.

Positioning things is one of the hardest things in IT.

Bruno Borges published a practical guide on configuring JDK 25 for GitHub Copilot Coding Agent - the ephemeral GitHub Actions environment where the agent builds code and runs tests. By default, the agent uses the pre-installed Java version on the runner, which can lead to failed builds if the project requires newer features. The solution? A dedicated copilot-setup-steps workflow with actions/setup-java.

Short, concrete, and useful if you’re starting to experiment with coding agents in Java projects.

SkillsJars is a new project showcased on the Coffee + Software livestream (Josh Long, DaShaun Carter, James Ward ) - a registry and distribution platform for Agent Skills via... Maven Central.

The idea is simple and simultaneously crazy in the best possible way: Agent Skills (the SKILL.md format introduced by Anthropic for Claude Code, also adopted by OpenAI Codex) are modular packages of instructions, scripts, and resources that extend AI agent capabilities - e.g., a skill for creating .docx documents, debugging via JDB, or building MCP servers. SkillsJars packages these skills as JAR artifacts and publishes them on Maven Central under the com.skillsjars group, with full support for Maven, Gradle, and sbt.

The catalog already includes a Spring Boot 4.x skill (best practices, project structure, configuration), an agentic JDB debugger by Bruno Borges, a browser automation skill (browser-use), and official Anthropic skills for creating presentations, PDFs, frontend design, and building MCP servers. Anyone can publish their own skill - just point it to a GitHub repo.

Maven Central as a package manager for agentic AI - we truly live in interesting times.

Johannes Bechberger from the SapMachine team at SAP created a fun quiz where you have to guess the minimum Java version required from a code snippet. Over 30 years, Java added generics, lambdas, pattern matching, records... and it turns out most of us can’t precisely recall which feature arrived in which version.

A perfect way to kill five minutes over coffee (or an hour, if you’re as nerdy as I am).

If you think it’s too easy... I dare you to try Java Alpha version with alpha features 😉

Akamas published an analysis of the state of Java on Kubernetes based on thousands of JVMs in production.

The findings? Despite it being 2026, most Java workloads on K8s run with default settings that actively hurt performance. 60% of JVMs have no Garbage Collector configured, most heap settings are at defaults, and a significant portion of pods run with less than 1 CPU or less than 1 GiB RAM - which is a serious bottleneck for Java’s multi-threaded architecture. An old problem, but the data is striking.

PS: Ergonomic Profiles was always a great Idea IMHO.

JetBrains released an extension for Visual Studio Code that enables converting Java files to Kotlin. The converter (J2K) uses the same engine as IntelliJ IDEA. Just open a .java file, right-click, and select “Convert to Kotlin.”

An interesting move - JetBrains clearly wants the Kotlin ecosystem to expand beyond their own IDE.

Robin Tegg, whose piece on Java UI landed in the newsletter two weeks ago, created an awesome page - a comprehensive guide to Java UI frameworks, from desktop (JavaFX, Swing, Compose Desktop) through web (Vaadin, HTMX, Thymeleaf) to terminal (TamboUI, JLine, Lanterna). The motivation? Frustration with outdated articles referencing dead libraries. The result is the best single source of knowledge on the current state of Java UI in 2026.

If anyone tells you “you can’t do UI in Java” - send them this link.

Scala Survey 2026 - VirtusLab and the Scala Center have launched their annual community survey, and if you’re using Scala in any capacity, your 5 minutes can directly shape the language’s roadmap, library ecosystem, and tooling priorities. The survey evaluates Scala adoption patterns, pain points, and what the community actually needs - and the results have historically influenced real decisions about where development effort goes.

Take the survey here. Whether you’re a daily Scala developer or someone who occasionally dips into the ecosystem, your perspective matters. That’s unique possibility to shape the language

To wrap this section - 100 most-watched presentations from Java conferences in 2025 is a solid list to catch up on. And the article on 10 modern Java features that let you write 50% less code is a good refresher, especially for those who are mentally stuck on Java 8.

2. Release Radar

Quarkus 3.31

Quarkus 3.31 is a major release that arrived after a two-month gap since the last feature release. The headline addition is full Java 25 support, but the changelog is genuinely impressive. New Panache Next - the next generation of the Panache layer with improved developer experience for Hibernate ORM and Hibernate Reactive. Upgrade to Hibernate ORM 7.2 and Reactive 3.2. Support for Hibernate Spatial. Upgrade to Testcontainers 2 and JUnit 6 (yes, JUnit 6!). New quarkus Maven packaging with a dedicated lifecycle. On top of that: security annotations on Jakarta Data repositories, OIDC token encryption, OAuth 2.0 Pushed Authorization Requests, headless AWT on Windows for native images, and much more. Requires Maven 3.9.0+.

Release Notes

Eclipse GlassFish 8.0

GlassFish 8, released February 5th, is the first production-ready implementation of the full Jakarta EE 11 platform. The release, led by the OmniFish team, brings support for virtual threads in HTTP thread pools and managed executors, an implementation of Jakarta Data (repositories for working with both JPA entities and Jakarta NoSQL entities), and a new version of Jakarta Security with more flexible authentication options. Integration with MicroProfile 7.1 (Config, JWT, REST Client, Health). Requires JDK 21 as a minimum, supports JDK 25. Led by Arjan Tijms, Ondro Mihályi, and David Matějček, GlassFish is returning as a serious production option.

Release Notes

Open Liberty 26.0.0.1

Open Liberty 26.0.0.1 is the first release of IBM’s application server in the new year - a transition from the 25.x branch to 26.x. The main addition is log throttling - a mechanism for automatically suppressing repeated log messages that simply didn’t exist in Liberty before. Throttling is enabled by default: Liberty tracks each messageID using a sliding window and after 1000 repetitions within five minutes begins suppressing messages, logging an appropriate warning. Throttling can be configured at the messageID or full message level (throttleType), and limits can be changed (throttleMaxMessagesPerWindow) - or disabled entirely by setting the limit to 0.

Security fixes include a patch for XSS (CVE-2025-12635, CVSS 5.4), issues with wlp password key decoding, and a NullPointerException in SocketRWChannelSelector. Two new guides on observability with OpenTelemetry and Grafana were also added.

Worth noting: the beta is developing a Model Context Protocol Server feature (mcpServer-1.0) - allowing Liberty application business logic to be exposed as tools for AI agents. Beta 26.0.0.2 has already added role-based authorization and async support. MCP in a Jakarta EE application server - now that’s an interesting combination.

Release Notes

BoxLang 1.9.0

BoxLang 1.9.0 announced as “production-ready” - a release focused on stability, with over 50 bug fixes, improved datasource lifecycle management (eliminating connection leaks), and better context management (eliminating memory leaks).

But what exactly is BoxLang? It’s a modern, dynamically typed JVM language from Ortus Solutions — a company well known in the ColdFusion world for the ColdBox framework and CommandBox tooling. BoxLang is essentially an answer to the question “what if we took the best ideas from CFML, Python, Kotlin, and Clojure, and built it from scratch on a modern JVM?” The language is 100% interoperable with Java, uses invokedynamic for performance, and its runtime weighs just ~6 MB. Interestingly, BoxLang has a dual parser — it can natively run existing ColdFusion/CFML code without modification, which is critical for migrations from Adobe ColdFusion or Lucee (and is also Ortus’s primary business model).

The project’s ambitions are broad — BoxLang targets multi-runtime deployment: from classic web servers, through AWS Lambda, to iOS, Android, and WebAssembly. The project is open source (Apache 2.0), with commercial BoxLang+ and BoxLang++ plans for enterprise support. Ortus also announced a cloud-native version at $5/month — a clear signal they’re trying to move beyond the ColdFusion niche and compete more broadly in the dynamic JVM language space.

Release Notes

Apache NetBeans 29

Apache NetBeans 29 - released February 23rd, so completely fresh. Under the hood there’s plenty of substance: Gradle Tooling API upgraded to 9.3.0, bundled Maven updated to 3.9.12, Ant bumped to 1.10.15. On the Java side — performance fixes for Find Usages and refactoring, better support for import module (keyword highlighting), fixed form designer.

Notably, NetBeans is already being tested on JDK 26-ea and sets --sun-misc-unsafe-memory-access=warn (JEP 498) — clearly laying the groundwork for upcoming changes to sun.misc.Unsafe access. The IDE supports running on JDK 25, 21, or 17, with preliminary support for JDK 26. Refactoring problem propagation to LSP clients has also been improved — NetBeans continues developing its role as a Language Server backend, not just a classic IDE.

Release Notes

Ktor 3.4.0

Ktor 3.4.0 - a new version of the Kotlin framework for building asynchronous HTTP servers and clients. A stability-focused release, but with several noteworthy additions. Most important: OpenAPI documentation generation from code — a new compiler plugin combined with the describe API lets you build a Swagger model dynamically, directly from the routing tree. No more manually maintaining static OpenAPI files that drift out of sync with the code.

Also added: Zstd compression support (Facebook’s algorithm offering an excellent compression-to-speed ratio) in the new ktor-server-compression-zstd module, duplex streaming for the OkHttp engine (simultaneous sending and receiving over HTTP/2), and a new HttpRequestLifecycle plugin - allowing in-flight requests to be automatically cancelled when a client disconnects. The last one is a nod to structured concurrency: a client disconnection cascades to cancel the coroutine handling the request along with all launch/async children, making resource management for long-running operations considerably cleaner. Currently works with Netty and CIO engines.

Release Notes

3. Github All-Stars

Krema - Tauri, but in Java

Krema is probably the most interesting new project in this edition. For those who know Tauri from the Rust ecosystem - Krema is its Java equivalent. Lightweight, native desktop applications using the system webview instead of a bundled Chromium. Backend in Java, frontend in React/Vue/Angular/Svelte, communication through a type-safe IPC bridge.

Key features: system webview (WebKit on macOS, WebView2 on Windows, WebKitGTK on Linux); native communication via Project Panama (Foreign Function & Memory API from Java 25) - no JNI, annotate Java methods with @KremaCommand and call them from the frontend with full type safety, plugin system (SQLite, WebSocket, file upload, window positioning, autostart), native packaging with GraalVM or as a JAR.

The project looks well thought-out, and if it develops, it could be a game-changer for desktop apps in Java.

TamboUI - Terminal UI for Java, finally taken seriously

TamboUI announced by Cédric Champeau (known from Gradle and Micronaut) and Max Rydahl Andersen (JBang, Red Hat ) - a modern Terminal UI framework for Java. It was born from the observation that Rust has Ratatui, Go has Bubbletea, Python has Textual - and Java? System.out.println and prayers.

TamboUI offers a multi-level API: from low-level widget primitives (like Ratatui), through a managed TUI with event handling, up to a declarative Toolkit DSL that handles the event loop and rendering thread for you. Immediate-mode rendering, constraint-based layout, CSS support, PicoCLI integration, multiple backends (JLine, Aesh, Panama).

And most importantly - full GraalVM native image compatibility, making Java a serious player in terminal tooling with low memory usage and fast startup. Core works on Java 8+, but it’s most enjoyable with modern Java idioms.

JADEx - Null Safety for Java Without Changing the Language

JADEx (Java Annotation-Driven Extensions) is an approach to null safety in Java through annotations and compile-time processing - without waiting for Valhalla or a language spec change. The discussion on r/java shows the topic is still very much alive, with demand for pragmatic solutions.

JOpus - Wrapper for the Opus Codec

JOpus is a high-performance Java wrapper for the Opus audio codec. Opus (not the one you might be thinking of) is an open audio format that excels at VoIP, streaming, and gaming - and is now easily accessible from the JVM.

ChartX - OpenGL Charting Library

ChartX is a library for creating hardware-accelerated charts using OpenGL. An interesting technology choice given that Minecraft is moving to Vulkan - but if you need performant, hardware-accelerated visualizations in Java, worth a look.

JBundle - Packaging JVM Applications

JBundle is a tool for packaging JVM applications into distribution-ready formats. In the era of jpackage and GraalVM native image, JBundle offers yet another option in the deployment tooling ecosystem.

As a wrap up, I have the invitation 😁

PS: The full KotlinConf’26 schedule is live - it’s officially time to start planning your conference experience! This year’s program highlights the ideas, tools, and real-world practices shaping the future of Kotlin. Over two days, you’ll hear from the Kotlin team and community experts as they share insights, experiments, and lessons learned from building at scale.

Amon speakers, you will find:

• Talking to Terminals (And How They Talk Back) | Jake Wharton

• Bootiful Kotlin | Josh Long

• Evolving Language Defaults | Michail Zarečenskij

• Practical Filament – Reshape Your UI! | Nicole Terc Vega

• Dissecting Kotlin: 2026 | Huyen Tue Dao

• Why Most AI Agents Never Scale: Building Enterprise-Ready AI With Koog | Vadim Briliantov

The full list you can find there.

For those who’ve been living under a rock: Let’s start with the Hitchhiker Guide to the Vibe Coded Lobster galaxy.

Let’s start from the beginning, because I know not all of you follow Twitter — though I have to admit, right now it’s (gulp) probably the most interesting social media out there (which is more of a commentary on the state of online discourse in 2026 than a compliment).

OpenClaw (formerly Clawdbot, then Moltbot - because Anthropic’s lawyers called) is an open-source AI agent created by Peter Steinberger. The project exploded in January 2026, racked up over 180,000 GitHub stars, spawned MoltBook (a social network for AI agents only, which my mom recently asked me about 🤯), and Steinberger himself just announced he’s joining OpenAI to - and I quote - “build the next generation of personal agents.”

The whole story is fascinating. Peter previously sold his company PSPDFKit for well over $100 million, went through three years of therapy and ayahuasca (yes, really), launched 43 projects, 42 flopped, and the 43rd hit the bullseye. Steinberger openly admits: “I never read parts of the code I shipped” - because OpenClaw is largely vibe-coded.

If someone had told me a few years ago that this is what programming would look like in the third decade - I wouldn’t have believed it.

Though my own Token Anxiety shows me just how addictive this process can be.

And to be clear: I’m genuinely interested in OpenClaw myself. I even built a client for it running on Reachy Mini - an open-source humanoid robot from Pollen Robotics/Hugging Face - and hooking it up to OpenClaw was freaking fun. Reachy Mini is fantastic hardware at $299, with a Python SDK and Hugging Face integration - the perfect toy for someone who (like me) wrote their bachelor’s thesis on controlling a robotic arm with a Kinect.

But just because something is fun doesn’t mean it’s above criticism. And I’m not talking about OpenClaw here.

I’m talking about a tweet that triggered a wave of frustration in the JVM community. A tweet in which 300,000 lines of unaudited TypeScript are presented as proof that traditional enterprise is dead. A tweet racking up hundreds of thousands of views, amplifying a narrative that everyone recruiting Java developers is already fighting.

So let’s talk about what actually lies behind that narrative. From both sides.

Let’s start with facts, because anyone can rant with emotions. Ranting with receipts - that’s a different league.

OpenClaw as an idea is fascinating. OpenClaw as a production system is a security disaster documented by at least five independent organizations:

• CVE-2026-25253 (CVSS 8.8) - one-click RCE. The Control UI trusted gatewayUrl from query strings without validation and sent auth tokens over WebSocket. Clicking a single link = full instance compromise. Exploitable even on localhost.

• Cisco AI Defense tested the “What Would Elon Do?” skill - 9 vulnerabilities, 2 critical. Silent data exfiltration and prompt injection bypassing safety guidelines. Their verdict, verbatim: “From a security perspective, it’s an absolute nightmare.”

• Snyk ToxicSkills - the first comprehensive ecosystem audit: 3,984 skills, 36% contain prompt injection, 341 malicious, including 335 installing Atomic Stealer on macOS. 76 confirmed credential-stealing payloads.

• Moltbook leak - misconfigured Supabase instance: 1.5 million API tokens, 35,000 email addresses, private messages between agents. All publicly accessible.

• 135,000+ instances exposed to the internet - the gateway binds to 0.0.0.0:18789 by default. SecurityScorecard tracked a jump from 40K to 135K in a single day. 63% classified as vulnerable.

• Adversa AI warns: ~/.openclaw/ stores API keys, WhatsApp tokens, and Discord credentials in plaintext JSON and Markdown. Infostealers RedLine, Lumma, and Vidar are already building modules to harvest these files.

• Gartner rated it an “unacceptable cybersecurity risk” - immediate ban recommended for enterprise.

And NanoClaw by Gavriel Cohen rewrote the core logic in ~500 lines of TypeScript. Five hundred. Auditable in a single afternoon. That says enough about the state of the original 300,000.

My problem isn’t with OpenClaw - as I said, my inner nerd is having the time of his life... in general, it’s fun. My problem is with the narrative in which a vibe-coded agent with three CVEs, 341 malware skills, and Gartner saying “ban this” gets presented as the future of programming - while an ecosystem with 30 years of production history is “boomer tech.”

Honest about Java’s problems - because we’re not fanboys

The rant edition format makes it easy to slip into Java is doing great, haters gonna hate mode. I’m not going there.

Java is unfortunately dropping in rankings - TIOBE February 2026: fourth place, ~8-9%. C# was named Language of the Year 2025. Paul Jansen openly asks whether “Java, with its verbose, boilerplate-heavy style and Oracle ownership, can continue to keep C# at bay.” Python is at 22%+. Rust - “most admired” for the ninth year running (82.2%). TypeScript has overtaken Java on GitHub. Stack Overflow 2025: only 15.8% of developers want to work in Java.

On top of that, the AI narrative favors Python and TypeScript - and not without reason. Vibe coding, agents, OpenClaw, Cursor, Claude Code - that’s TypeScript and Python. The feedback loop is shorter, the entry barrier lower, and LLMs generate better code in languages they were trained on. If you’re a junior in 2026, your first AI project will be in Python. One hundred percent. That’s a real problem for the JVM talent pipeline.

Unfortunately, Java is still perceived through the lens of version 8. It’s an ugly vicious cycle: the more people think of Java in terms of EJBs, getters, and AbstractSingletonProxyFactoryBean, the fewer newcomers bother to check what’s changed, which cements the image of an “old” language. We don’t help ourselves either — many of us live in a bubble and aren’t explaining loudly enough that Java 25 is a completely different language than Java 8.

These are real problems. Treating them as “hate” instead of signals is a mistake.

Now - the counterattack. Because the data tells a more interesting story than the Twitter narratives.

The JVM ecosystem hasn’t been sitting still. The GraalVM team, among others, decided to remind the world of a few facts. Rightly so.

Bruno Borges, Developer Advocate at GitHub (previously Microsoft, Oracle), created java.evolved - a site comparing old Java code with its modern equivalent. 86 comparisons, JDK 8 to JDK 25.

Take a look:

// Back then
public class Point {
    private final int x, y;
    public Point(int x, int y) { ... }
    public int getX() { return x; }
    public int getY() { return y; }
    // equals, hashCode, toString...
}

// Java 16+
public record Point(int x, int y) {}

// Back then
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

// Java 25
void main() {
    println("Hello, World!");
}

Virtual threads. Structured concurrency. Pattern matching in switch. Sealed classes. Gatherers in streams. This is not the same Java people picture when they say “enterprise bloat.”

So first action point from this piece: java.evolved - worth sending to anyone still citing Java circa 2015.

Now let’s look at an alternative perspective our community has been wielding like a shield - Thiago Mendes published an open-source benchmark of MCP servers in four languages - 3.9 million requests, three rounds, full code on GitHub. Each server in an identical Docker container (1 core, 1GB RAM), four identical test tools.

The headline number: Java (Spring Boot + Spring AI) achieved 0.835ms average latency vs Python (FastMCP) at 26.45ms. A 31x difference. Go right next to Java (0.855ms), Node.js in the middle (10.66ms).

But - let’s be honest - raw MCP server latency is rarely the bottleneck in practice. A typical flow looks like: LLM generates request (500–2000ms) → MCP routes to tool (those 0.8–26ms) → tool queries database/API (50–3000ms) → LLM processes response (500–2000ms). The bottleneck is the LLM - by a huge margin. Those 25ms difference between Java and Python drown in the seconds the model spends thinking. The end user won’t feel it. I think anyone who’s used any MCP in practice will confirm that.

Where this data actually matters is resource efficiency under load. And here the table says more than the latency numbers:

Java and Go handle 1600 req/s using ~30% CPU. They have headroom. Add more load - they’ll hold. Python and Node.js are already hitting the wall at 50 concurrent users. In practice that means: if you’re building an MCP gateway for one developer - Python is fine. If you’re building shared MCP infrastructure for an organization with hundreds of agents - the difference between 30% and 94% CPU utilization is the difference between “it works” and “we need three times as many Kubernetes pods.”

Disclaimer: Node.js with per-request instantiation (mitigation for CVE-2026-25536 - shared instance would be faster), Python with single-worker uvicorn (multi-worker would improve things), Java without JVM tuning.

So the Java is 31x faster than Python in AI claim - I wouldn’t push that too hard people. More accurately: Java and Go give you headroom that Python and Node.js don’t have, when MCP stops being a single developer’s toy and becomes infrastructure.

Which is exactly what I’d expect from it.

Moving on: the Azul 2026 State of Java Report (2000+ respondents) shows 62% using Java for AI functionality - up from 50% the year before. 31% say more than half of their Java applications contain AI.

Standard disclaimer from my side (of which there are many today) - this is a survey of people who already use Java, so there’s naturally a bias. But the trend is clear: Python dominates in prototyping and experimentation, Java in production.

The New Stack quotes Gil Tene, CTO of Azul:

People are not playing around making little demos; they’re making real applications with Java for AI.

The report summarizes it this way:

While Python might never relinquish its position as the top programming language for producing AI functionality, Java is becoming the default language for running the AI applications themselves.

Python prototypes. Java produces. Both are needed. But only one of them keeps banking systems on their feet at three in the morning.

One more thing that kind of blew my mind: 98% of respondents use AI tools to generate code (last year: 76%). 30% say more than half of new code is entirely AI-generated.

The “irrelevant in the AI era” ecosystem looks rather different in my head.

The about section of this newsletter has always featured a certain comic strip:

And as always, it’s still relevant.

“Java is dead” is its own literary genre by now. Paul Graham himself weighed in back in 2001 - we’ve had time to get used to it. Java survived applets, EJB, “XML everywhere,” the rise of Scala, Kotlin, Node.js, Go, Rust, and Python-as-the-one-true-language. It will survive “vibe coding killed enterprise Java” too.

But survival doesn’t mean no problems. Java has a real mindshare gap among new developers - and with every tweet like Steinberger’s, that gap widens. Few people have that kind of reach today.

Peter Steinberger is a great builder - this is definitely the Age of Builders. What’s more, OpenClaw is a fascinating project. But 300,000 lines of unaudited code with 135K open instances, Cisco catching malware in skills, Snyk finding 341 malicious packages, and Gartner saying “ban this” - that’s not proof that enterprise is dead. That’s proof that adoption ≠ quality. We are not living in the age of polished, Apple-like experience, I agree, but there is a need for both approaches.

And the narrative that “real programmers vibe, and the rest are enterprise boomers” is toxic. We should name it for what it is.

PS: Even if you’re up to date, still browse java.evolved yourself - 86 old-vs-modern comparisons are satisfying on an almost therapeutic level. Like organizing a sock drawer, but for programmers.