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.

Recent weeks are exceptionally juicy when it comes to “fundamentals.” We have two really big moves on the OpenJDK mailing lists - one I’ve been waiting for a long time, and another that could change the way we think about classes in Java. Plus two items from the ecosystem that are begging for attention. Let’s go.

1. Code Reflection Gets Its JEP - and Babylon Finally Speaks to GPUs in Java

Some of you probably remember that I’ve been repeating like a mantra for a while now that Project Babylon is one of the most exciting endeavors in the OpenJDK ecosystem. And at last we have something concrete to talk about - JEP draft: Code Reflection (Incubator), owned by Paul Sandoz, with reviewers including Adam Sotona , Juan Fumero , and Maurizio Cimadamore . The very composition of such a trio should give you pause - we’re connecting the worlds of core Java, hardware accelerators, and the Foreign Function API.

Let’s start with what Code Reflection actually is, because I know not everyone follows Babylon as obsessively as I do. Traditional reflection in Java let us inspect classes, fields, and methods — but not the code inside those methods. Let me repeat: from Java 1.1 to today, reflection lets you find out that the method add takes two ints and returns an int, but doesn’t let you look inside and see what that method does. Code Reflection changes this situation fundamentally.

The mechanism works like this: we annotate a method or lambda expression with @Reflect (formerly @CodeReflection - the name refactoring is fairly recent). The javac compiler translates the internal code model into a standard code model - an immutable tree of code elements - and saves it in a separate class file associated with the original class. At runtime, we can retrieve this model via the API: Op.ofMethod(method) for methods, Op.ofLambda(instance) for lambdas. Sounds simple? Conceptually it is - but the consequences are enormous.

Because what can you do with a code model? You can traverse it, build one from scratch, transform it - and translate it into something entirely different. The JEP explicitly talks about “foreign programming models,” and GPU is the flagship example here. Instead of embedding CUDA C as strings in Java code (yes, people did this), you can write a normal Java lambda, annotate it with @Reflect, and let a library translate it into GPU code:

dispatchKernel((@Reflect IntConsumer) i -> {
    byte r = rgbImage[i * 3 + 0];
    byte g = rgbImage[i * 3 + 1];
    byte b = rgbImage[i * 3 + 2];
    grayImage[i] = gray(r, g, b);
});

This isn’t pseudocode but a real vision of how a GPU library could work, extracting the code model from a lambda and generating the appropriate kernel from it. Crucially, the JEP explicitly emphasizes that it is not a goal for the JVM itself to run code on GPUs. This is a primitive that gives libraries the tools to do so. Just as the FFM API knows nothing about GPUs but lets you talk to them. The philosophy is the same: the platform provides building blocks, the ecosystem builds solutions from them.

And that leads us to the second link in this section, which is a natural complement to the JEP. Juan Fumero (from the JEP’s review group - coincidence? I think not) published an extensive article on optimizing matrix multiplication on GPUs from Java using Babylon and HAT (Heterogeneous Accelerator Toolkit). The article is technical, but it’s worth pushing through - because it shows what the practical use of Code Reflection looks like on the example of one of the most important algorithms of the AI era.

HAT is a framework built on Babylon that offers several key abstractions: an ND-Range API for defining GPU thread configurations (similar to OpenCL or CUDA), a Kernel-Context Layer for expressing per-thread code, a Compute-Context Layer for orchestrating multiple kernels, and an Interface Mapper for efficient memory mapping between CPU and GPU (based on Panama FFM). The programmer writes a Java method annotated with @Reflect, HAT extracts the code model from it, performs transformations, and generates the appropriate CUDA or OpenCL program.

And now for the numbers, because they speak louder than a thousand paragraphs. Fumero performs 1024×1024 matrix multiplication on an NVIDIA A10 GPU, step by step optimizing the kernel: from naive 1D, through 2D, coalesced memory access, loop tiling with shared memory, register tiling, vectorization, all the way to FP16. The result? A jump from ~7 GFLOP/s on CPU (Java parallel streams) to ~14 TFLOP/s on GPU - close to native cuBLAS. Yes, you read that right: code written in Java, translated to CUDA by Babylon+HAT, achieves performance comparable to NVIDIA’s native library.

Not bad... not bad at all.

This changes the perspective. Project Sumatra in the 2010s tried to hide the GPU from the programmer - and failed, because GPUs are a fundamentally different execution model (”Single instruction, multiple threads”, separate memory, no polymorphism). HAT approaches this completely differently: it doesn’t pretend GPUs don’t exist but gives the Java developer tools for consciously programming for that architecture. And thanks to Code Reflection, it does so without leaving Java.

It’s worth adding that GPUs are just one of the use cases. The JEP explicitly mentions automatic differentiation, translating Java to SQL, and passing translated code to native ML runtimes. In an era where every framework wants to have an “AI story,” Java is getting the foundation on which that story can be told without needing to escape to Python at every tu

PS: The topic of GPUs in Java is particularly close to my heart, because just a week ago I had the chance to talk about it live - at Jfokus in Stockholm I presented JVM in the Age of AI, where a significant part of the talk was dedicated to how Java is reaching for the GPU and why Babylon changes the rules of the game. The repo I linked has an set of different technologies already set-up, so you can check them by yourself.

2. Carrier Classes - Brian Goetz Beyond Records, or the End of the “Cliff”

Brian Goetz published on amber-spec-experts one of those posts where it’s worth sitting down with a coffee, because it changes the map of where data-oriented programming in Java is heading. Title: Data Oriented Programming, Beyond Records - and yes, it’s exactly as big as it sounds.

The problem is well known to anyone who has ever started with a record and then realized they needed even one mutable field, or an internal representation different from the API, or inheritance. The result? A “cliff” - you fall off the full set of record benefits (automatic constructor, accessors, equals/hashCode/toString, destructuring in pattern matching) straight down to a bare class where you have to write all of it manually.

Visualization of your miserable experience.

Goetz explicitly calls this a problem and finally proposes a solution - carrier classes.

A carrier class is a regular class declared with a state description, exactly like a record — but without record restrictions. It doesn’t have to be final. Fields don’t have to be final. It can inherit from something other than Record. The only commitment: the state description is a complete, canonical, nominal description of the object’s state — meaning if you extract those components and reconstruct the object, you get an “equivalent” instance. In return, the language gives you almost everything it gives records: deconstruction in pattern matching, sensible default Object methods, and (crucially!) support for the upcoming reconstruction with with expressions (JEP 468).

What excites me most about this proposal is the approach to bridging between the API and internal representation. Goetz introduces the concept of component fields — fields marked with the component modifier that tell the language: “this field is a direct representation of a component from my state description.” This lets the compiler generate an accessor — exactly like in records.

And when there isn’t a direct mapping? Goetz illustrates this with an elegant example of a class with state description (int x, int y, Optional<String> s) that internally stores s as a nullable String. In a record, this is impossible — the state description is the representation. In a carrier class, you write only the few lines that handle the difference: conversion in the constructor and in the accessor. The rest is derived.

This is actually the key motif of the entire document — the amount of help from the language should be proportional to the deviation from the record ideal. The closer to a record, the less code you write. The further away — the more, but only as much as the actual differences require. No cliff. Goetz literally writes:

It would be nice if the author of this class only had to write the code that was different from what we could derive for a record.

Compact constructors also get generalized. In records, the compact constructor frees you from assigning parameters to fields. In carrier classes, it frees you from initializing component fields, leaving you responsible only for fields that don’t map directly to components. In the extreme case, when all components have their component fields and you don’t need any additional logic — you can skip the compact constructor entirely. The end result looks like this:

class Point(int x, int y) {
    private /* mutable */ component int x;
    private /* mutable */ component int y;
    // derived: compact constructor, accessors, equals, hashCode, toString
    // supports: pattern matching, with-expressions
}

For someone who has been watching for years as Amber step by step builds a coherent vision of data-oriented programming, this document is a breakthrough moment. Records, sealed classes, and pattern matching were the first story arc. Carrier classes, with their generalized state description, compact constructors, and component fields, open the second arc - and finally provide the answer to the question that has been hanging in the air since JDK 14: “What if my class is almost a record?”

But man does not live by the JDK alone - let’s move on to the ecosystem.

3. Gatherers in Practice - or Why Data Structures Still Matter

Gatherers are one of those things that “finally” made it into the standard library (with finalization in JDK 24), but their practical applications are only now crystallizing in developers’ heads. Grzegorz Piwowarek, current maintainer of Vavr, decided to change that, presenting a case study of implementing a Gatherer that returns the last N elements of a stream - like limit() from the other end.

And here’s the catch, because his article Implementing Efficient Last Stream Elements Gatherer in Java isn’t a dry tutorial on “how to implement a Gatherer.” It’s a story about optimization, profiling, and choosing the right data structure - guided step by step, with JMH benchmarks and flamegraphs from async-profiler. Grzegorz starts with a naive implementation on ArrayList, moves through buffering, ArrayDeque, circular buffer, all the way to power-of-two bit masking - and at each stage shows why the previous version was slow.

The results speak for themselves: from ~1.3 ops/s in the first version (where ArrayList.removeFirst() was copying the entire array on every element!) to over 100 ops/s in the final version with a circular buffer sized to a power of two. Nearly a hundredfold jump. And the climactic moment is dropping down to the assembly level, where Piwowarek shows that the modulo operation (sdiv + msub on ARM) costs 7 to 21 cycles, while a bitwise AND after aligning the size to a power of two - 1–2 cycles. That kind of detour through Integer.highestOneBit() and a bit mask is something that wouldn’t occur to you if you were coding “by eye” - but it makes a huge difference.

So yes - the article is ostensibly about Gatherers, but really about the fact that even in 2026, when we have Virtual Threads, Structured Concurrency, and AI-generated code, the ability to choose the right data structure and profile at the assembly level is still what separates “it works” from “it works well.” If you haven’t played with the Gatherers API yet - this is a great entry point. And if you have but haven’t done benchmarks - time to catch up.

4. True Gem: Java UI in 2026 - The Complete Guide

To finish, something that is a little gem in its own right - Robin Tegg, a developer from CreateFuture, compiled a complete overview of UI frameworks available in the Java ecosystem in 2026, divided into four platforms: desktop, web, mobile, and terminal.

Why is this a gem? Because nobody normally does compilations like this - and if they do, they’re either superficial or immediately outdated. Tegg covered 25+ frameworks (yes, really!), from obvious choices like JavaFX, Vaadin, and Compose Desktop, through Gluon Mobile and Codename One on mobile, all the way to terminals with JLine. Each framework gets a summary, a code example, and links to documentation. There’s also a “quick reference guide” organized by scenarios - looking for full-stack Java without JavaScript? Vaadin or Wicket. Cross-platform mobile? Codename One. And so on.

The article’s conclusion is one that’s hard to disagree with: Java UI development is alive, modern, and production-ready on every platform. React and the JavaScript ecosystem dominate in mindshare, but Java frameworks power critical applications in the largest enterprises, banks, and government institutions, serving hundreds of millions of users. Add to that the fact that most of the described frameworks are open source — so if you’re looking for something to contribute to or simply want to know what your options are — this is your starting point.

PS: I know this issue is a bit heavier than usual - but both the JEP on Code Reflection and Goetz’s post on carrier classes are documents worth reading in full. If you only have time for one, go with Goetz - carrier classes are about the everyday code we all write. The Babylon JEP is wonderful, but if you’re not programming GPUs or writing frameworks, it’s more of a medium-term perspective (though a fascinating one).

And let’s be honest - who among us hasn’t had an “almost-record” in their life? 😉

Today I’m handing over the main feature to a guest author. Recently on the foojay.io, David Parry from Qodo published what I consider one of the best technical deep-dives on MCP I’ve ever read. If you’ve been scratching your head about how AI assistants actually communicate with external tools - not at the SDK level, but at the raw protocol level - this is the piece you’ve been waiting for.

I asked David (in person, as we are both on Jfokus Today!) whether he’d let me feature it in JVM Weekly. The answer was a “yes” ❤️.

Understanding MCP Through Raw STDIO Communication

Ever wondered how AI assistants like Claude actually communicate with external tools and services? While most tutorials focus on using pre-built SDKs and frameworks, this article takes a different approach—we’ll dissect a production MCP server built from scratch using only Java’s standard libraries and raw STDIO communication.

By stripping away all the abstractions and implementing the Model Context Protocol directly, we’ll uncover the surprisingly elegant mechanics that enable AI systems to discover, understand, and execute tools.

Whether you’re building AI integrations, debugging mysterious protocol errors, or simply curious about what really happens when an AI “uses a tool,” this deep dive will transform JSON-RPC messages flowing through stdin/stdout from abstract concepts into concrete, debuggable reality.

No frameworks, no magic—just the protocol in its purest form.

Want to build this yourself? This article is based on code from the Agent MCP Workshop, an instructor-led workshop that guides you through building a complete MCP server from scratch. The workshop includes hands-on exercises, detailed explanations, and practical examples that complement the concepts discussed in this article.

Understanding MCP Through Raw STDIO Communication

The Model Context Protocol (MCP) represents a paradigm shift in how AI systems interact with external tools and data sources. This article dives deep into the protocol’s STDIO-based communication layer, examining a real-world Java implementation built without frameworks to better understand how the protocol and communication actually work at the fundamental level.

By implementing MCP from scratch using only standard Java libraries, we gain invaluable insights into the protocol’s inner workings—insights often hidden by higher-level abstractions and frameworks. This bare-metal approach reveals the elegant simplicity underlying MCP’s powerful capabilities.

Why STDIO? The Power of Universal Communication

Before diving into the implementation, it’s crucial to understand why MCP chose STDIO (Standard Input/Output) as its primary transport mechanism. STDIO provides:

• Universal compatibility: Every programming language can read from stdin and write to stdout

• Process isolation: Natural security boundaries between the AI client and tool server

• Simplicity: No network configuration, firewall rules, or authentication complexity

• Debugging ease: Messages can be logged, inspected, and replayed

This implementation demonstrates these principles by building everything from scratch—no MCP SDK, no framework dependencies, just pure Java interacting with STDIO streams.

At the heart of any MCP implementation lies a robust transport layer. The Java implementation demonstrates a clean separation of concerns through its I/O handler architecture:

public class IOHandlerImpl implements IOHandler {
    private final static LogFile logger = LogFileWriter.getInstance();
    private final PrintWriter writer;
    private final List<Consumer<String>> lineListeners;
    private final AtomicBoolean running;
    private final Gson gson = new Gson();
    @Override
    public void emit(Object message) {
        String text = gson.toJson(message);
        logger.log("[API][SENT]: " + text);
        writer.println(text);
        writer.flush();
    }
    @Override
    public void startInputReader() {
        if (running.get()) {
            return; // Already running
        }
        try (Scanner scanner = new Scanner(System.in)) {
            running.set(true);
            while (running.get()) {
                if (!scanner.hasNextLine()) {
                    running.set(false);
                    break;
                }
                String line = scanner.nextLine();
                logger.log("[API][RECEIVED]" + line);
                publishLine(line);
            }
        }
    }
}

This implementation showcases several critical design decisions:

• Direct STDIO access: Reading from System.in and writing to System.out without buffering frameworks

• Thread-safe operations using AtomicBoolean and CopyOnWriteArrayList

• Event-driven architecture with listener patterns for incoming messages

• Line-based protocol: Each JSON-RPC message is a complete line, enabling simple parsing

• Comprehensive logging that writes to files (never stdout!) for debugging

The beauty of this approach is its transparency. When the server emits a message:

public void emit(Object message) {
    String text = gson.toJson(message);
    logger.log("[API][SENT]: " + text);  // Log to file, not stdout!
    writer.println(text);  // Send to stdout
    writer.flush();        // Ensure immediate delivery
}

The message goes directly to stdout as a single line of JSON. No framing, no length prefixes, no binary protocols—just newline-delimited JSON that any tool can read and debug.

Understanding the JSON-RPC Message Flow

MCP uses JSON-RPC 2.0 over STDIO, which means every message is a self-contained JSON object on a single line. Let’s trace through an actual message exchange to see how this works:

Client → Server: Initialization Request

{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"0.1.0","capabilities":{"roots":{},"sampling":{}},"clientInfo":{"name":"mcp-inspector","version":"0.1.0"}},"id":0}

This single line contains everything needed for initialization. The server reads it from stdin using:

String line = scanner.nextLine();
logger.log("[API][RECEIVED]" + line);
publishLine(line);  // Notify the router

Server → Client: Initialization Response

{"jsonrpc":"2.0","id":0,"result":{"protocolVersion":"0.1.0","capabilities":{"tools":{},"prompts":{},"resources":{}},"serverInfo":{"name":"agent-mcp-workshop","version":"0.0.1"}}}

The server writes this response directly to stdout. No HTTP headers, no WebSocket frames - just a line of JSON followed by a newline character.

The Message Type Hierarchy

The implementation uses Java records to model the JSON-RPC message types:

public record JsonRpcRequest(
    String jsonrpc,
    Long id,
    String method,
    Object params
) {}

public record JsonRpcNotification(
    String jsonrpc,
    String method,
    Object params
) {}  // Note: No id field for notifications!

public record JsonRpcResponse(
    String jsonrpc,
    Long id,
    Object result
) {}

public record JsonRpcErrorResponse(
    String jsonrpc,
    Long id,
    JsonRpcError error
) {}

This type system directly maps to the JSON-RPC 2.0 specification, making the protocol implementation clear and type-safe.

Every MCP session begins with a crucial initialization handshake. The implementation demonstrates how servers advertise their capabilities:

case INITIALIZE -> {
    InitializeParams initializeParams = deserializer.deserializeParams(
        message, InitializeParams.class
    );
    ClientCapabilities clientCapabilities = initializeParams.capabilities();
    if (clientCapabilities.roots() != null) {
        hasRoots = true;
    }
    if (clientCapabilities.sampling() != null) {
        hasSampling = true;
    }
    InitializeResultBuilder builder = InitializeResultBuilder
            .builder()
            .withProtocolVersion(initializeParams.protocolVersion())
            .withDefaultCapabilities()
            .withDefaultServerInfo();
    success(message.id(), builder.build());
}

This approach allows servers to clearly declare what they support, enabling intelligent capability negotiation between clients and servers.

Bidirectional Communication: Beyond Request-Response

One of MCP’s powerful features is true bidirectional communication. The server can send requests to the client, not just respond to them. This implementation demonstrates this with the roots feature:

case NOTIFICATIONS_INITIALIZED -> {
    // Server initiates a request to the client!
    if (hasRoots) {
        io.emit(rootsRequest);
    }
}

The rootsRequest is a server-initiated message:

private static final JsonRpcRequest rootsRequest = new JsonRpcRequest(
    JSON_RPC_VERSION, 
    ROOTS_REQUEST_ID,  // Negative ID to avoid conflicts
    "roots/list", 
    null
);

When the client responds, the server processes it just like any other response:

private void process(JsonRpcResponse message) {
    if (ROOTS_REQUEST_ID.equals(message.id())) {
        RootsResponse rootsResponse = deserializer.deserializeResult(
            message, RootsResponse.class
        );
        roots.clear();
        for (Root root : rootsResponse.roots()) {
            roots.add(root.uri());
        }
    }
}

This bidirectional flow over STDIO demonstrates that MCP isn’t limited to simple request-response patterns—it’s a full-duplex protocol where both parties can initiate communication.

The routing mechanism demonstrates how MCP servers handle different message types:

public void route(String message) {
    if (message == null || message.isEmpty()) {
        return;
    }
    Object object = deserializer.deserialize(message);
    switch (object) {
        case JsonRpcRequest request -> process(request);
        case JsonRpcNotification notification -> process(notification);
        case JsonRpcResponse successResponse -> process(successResponse);
        case JsonRpcErrorResponse errorResponse -> process(errorResponse);
        default -> logger.log("Unknown message type: " + object);
    }
}

This pattern matching approach (using Java’s modern switch expressions) creates a clean, extensible routing system. Each message type has its own processing logic:

private void process(JsonRpcRequest message) {
    UniqueKeys uniqueKey = UniqueKeys.fromValue(message.method());
    switch (uniqueKey) {
        case INITIALIZE -> { /* ... */ }
        case PROMPTS_LIST -> { /* ... */ }
        case PROMPTS_GET -> { /* ... */ }
        case TOOLS_LIST -> { /* ... */ }
        case TOOLS_CALL -> { /* ... */ }
        case RESOURCES_LIST -> { /* ... */ }
        case RESOURCES_READ -> { /* ... */ }
        case PING -> { /* ... */ }
        default -> logger.log("Unhandled RpcRequest method: " + uniqueKey);
    }
}

The Complete STDIO Loop: Putting It All Together

Let’s trace through a complete interaction to see how STDIO communication enables MCP:

1. Server Startup

public void start() {
    // Register the router to handle incoming lines
    this.io.addLineListener(router::route);

    // Start reading from stdin in a separate thread
    this.io.startInputReader();

    // Keep the main thread alive
    keepRunning();
}

2. Client Connects (via process spawn)

The client spawns the server process and connects to its stdin/stdout:

java -jar agent-mcp-workshop-0.0.1.jar

3. Message Exchange Begins

→ [stdin]  {"jsonrpc":"2.0","method":"initialize","params":{...},"id":0}
← [stdout] {"jsonrpc":"2.0","id":0,"result":{...}}
→ [stdin]  {"jsonrpc":"2.0","method":"notifications/initialized"}
← [stdout] {"jsonrpc":"2.0","method":"roots/list","id":-1000}
→ [stdin]  {"jsonrpc":"2.0","id":-1000,"result":{"roots":[...]}}

Each arrow represents a complete line written to stdin or stdout. The server never writes partial messages or multiple messages on one line—maintaining the protocol’s simplicity.

4. Error Handling Without Exceptions

Since STDIO doesn’t have error channels like HTTP status codes, errors are part of the protocol:

success(message.id(), ToolCallResultBuilder
    .builder()
    .addTextContent("Tool not found: " + toolCallParams.name())
    .asError()
    .build());

This creates a valid response with an error flag, keeping the STDIO stream clean and the protocol predictable.

The keyword search tool demonstrates how to create self-describing, executable functionality:

public class KeyWordSearch implements Tool {
    @Override
    public String name() {
        return "key_word_search";
    }

    @Override
    public String description() {
        return "Searches for a specified keyword across all files in a project. " +
               "Returns the total count of matches and the absolute file paths " +
               "of the files containing the keyword.";
    }

    @Override
    public InputSchema schema() {
        InputSchemaBuilder builder = InputSchemaBuilder
                .builder()
                .withType("object")
                .addProperty(PropertySchemaBuilder
                        .builder()
                        .withKey("keyword")
                        .withType("string")
                        .withDescription("the keyword to search for in a file")
                        .required());
        if (this.roots == null || this.roots.isEmpty()) {
            builder.addProperty(PropertySchemaBuilder
                    .builder()
                    .withKey("root_directory")
                    .withType("string")
                    .withDescription("The absolute path to the root directory")
                    .required());
        }
        return builder.build();
    }
}

The schema definition is particularly important—it enables AI clients to understand exactly how to invoke the tool. The actual implementation showcases robust file handling:

public ToolCallResult call(ToolCallParams toolCallParams) {
    String keyword = toolCallParams.arguments().get("keyword");
    ToolCallResultBuilder builder = ToolCallResultBuilder.builder();

    if (roots.isEmpty()) {
        builder.addTextContent("No root directories specified for search.");
        builder.asError();
    } else {
        List<ContentItem> contentItems = searchKeywordInDirectories(roots, keyword);
        builder.withContent(contentItems);
    }
    return builder.build();
}

Debugging STDIO Communication

One of the advantages of building MCP without frameworks is the ability to debug at the protocol level. The implementation includes comprehensive logging:

logger.log("[API][RECEIVED]" + line);  // Every incoming message
logger.log("[API][SENT]: " + text);     // Every outgoing message

This creates a complete trace of the STDIO communication:

[2024-01-15 10:23:45] [API][RECEIVED]{"jsonrpc":"2.0","method":"tools/list","id":5}
[2024-01-15 10:23:45] [API][SENT]: {"jsonrpc":"2.0","id":5,"result":{"tools":[{"name":"key_word_search","description":"Searches for a specified keyword...","inputSchema":{...}}]}}
[2024-01-15 10:23:46] [API][RECEIVED]{"jsonrpc":"2.0","method":"tools/call","params":{"name":"key_word_search","arguments":{"keyword":"TODO"}},"id":6}
[2024-01-15 10:23:47] [API][SENT]: {"jsonrpc":"2.0","id":6,"result":{"content":[{"text":"/src/main/java/Server.java, keyword_count=3","type":"text"}]}}

This trace can be replayed for testing, analyzed for performance, or used to debug protocol issues—something much harder with framework-heavy implementations.

case RESOURCES_LIST -> {
    ResourcesListResultBuilder builder = ResourcesListResultBuilder
            .builder()
            .withResources(JavadocResources.loadAllHtmlResourcesFromFolder(
                "javadoc/com/workshop/mcp/spec"
            ))
            .withNextCursor("pageNext");
    success(message.id(), builder.build());
}

The JavadocResources class shows sophisticated resource handling:

public static String readResourceContent(String resourcePath) throws IOException {
    try (InputStream inputStream = JavadocResources.class.getClassLoader()
                                                         .getResourceAsStream(resourcePath)) {
        if (inputStream == null) {
            throw new IOException("Resource not found: " + resourcePath);
        }

        try (BufferedReader reader = new BufferedReader(
                new InputStreamReader(inputStream))) {
            return reader.lines().collect(Collectors.joining("\n"));
        }
    }
}

This approach allows servers to bundle and serve documentation, configurations, or any other static content directly from the JAR file—all transmitted as JSON over STDIO. When a client requests a resource:

→ {"jsonrpc":"2.0","method":"resources/read","params":{"uri":"javadoc/com/workshop/mcp/spec/Tool.html"},"id":10}
← {"jsonrpc":"2.0","id":10,"result":{"contents":[{"uri":"javadoc/com/workshop/mcp/spec/Tool.html","mimeType":"text/html","text":"<!DOCTYPE HTML>..."}]}}

The entire HTML document is embedded in the JSON response, properly escaped and transmitted as a single line. This demonstrates STDIO’s flexibility—it can handle everything from simple method calls to large content transfers.

Prompts: Bridging Human Intent and Tool Execution

The prompt system creates user-friendly interfaces for tools:

case PROMPTS_LIST -> {
    KeyWordSearch keyWordSearch = new KeyWordSearch(this.roots);
    PromptsListResultBuilder builder = PromptsListResultBuilder
            .builder()
            .withPrompt("search_keyword",
                        "Creates a prompt, to search for a word using the " + 
                        keyWordSearch.name() + " tool.")
            .withPromptArgument("keyword", "The word to search for", true)
            .withNextCursor("nextPage");
    success(message.id(), builder.build());
}

When retrieving a prompt, the server can provide intelligent guidance:

case PROMPTS_GET -> {
    PromptsGetParams params = deserializer.deserializeParams(
        message, PromptsGetParams.class
    );
    PromptsGetResultBuilder builder = PromptsGetResultBuilder
            .builder()
            .withDescription("keyword")
            .addTextMessage("user", KEY_WORD_MESSAGE, params.arguments());
    success(message.id(), builder.build());
}

Advanced Features: Notification Handling

The implementation includes sophisticated notification handling:

private void process(JsonRpcNotification message) {
    UniqueKeys uniqueKey = UniqueKeys.fromValue(message.method());
    switch (uniqueKey) {
        case NOTIFICATIONS_INITIALIZED -> {
            if (hasRoots) {
                io.emit(rootsRequest);
            }
        }
        case NOTIFICATIONS_ROOTS_LIST_CHANGED -> {
            io.emit(rootsRequest);
        }
        case NOTIFICATION_CANCELLED -> {
            NotificationCancelledParams params = deserializer.deserializeParams(
                message, NotificationCancelledParams.class
            );
            logger.log("Notification cancelled reason " + params.reason());
        }
        default -> logger.log("Unhandled notification method: " + uniqueKey);
    }
}

This shows how servers can react to client-side events and maintain synchronized state.

Server Lifecycle Management

The Server class demonstrates robust lifecycle management:

public class Server {
    private final AtomicBoolean isShuttingDown = new AtomicBoolean(false);
    private final CountDownLatch shutdownLatch;

    public void start() {
        try {
            this.io.addLineListener(router::route);

            Runtime.getRuntime().addShutdownHook(new Thread(() -> {
                if (isShuttingDown.compareAndSet(false, true)) {
                    stop();
                    logger.close();
                    shutdownLatch.countDown();
                }
            }));

            this.io.startInputReader();
            keepRunning();
        } catch (Exception e) {
            logger.log("Error in main method", e);
            stop();
            System.exit(0);
        }
    }
}

The use of shutdown hooks and countdown latches ensures graceful termination even in complex scenarios.

Key Architectural Patterns

1. Record Types for Protocol Messages

public record JsonRpcRequest(
    String jsonrpc,
    Long id,
    String method,
    Object params
) {}

Java records provide immutable, self-documenting protocol structures.

2. Builder Pattern for Complex Responses

InitializeResult result = InitializeResultBuilder.builder()
    .withProtocolVersion("1.0")
    .withServerInfo("my-server", "1.0.0")
    .withDefaultCapabilities()
    .build();

Builders ensure valid, complete responses while maintaining readability.

3. Enum-Based Method Routing

public enum UniqueKeys {
    INITIALIZE("initialize"),
    NOTIFICATIONS_INITIALIZED("notifications/initialized"),
    PROMPTS_LIST("prompts/list"),
    // ... more methods

    public static UniqueKeys fromValue(String value) {
        for (UniqueKeys key : UniqueKeys.values()) {
            if (key.value.equalsIgnoreCase(value)) {
                return key;
            }
        }
        return NOT_FOUND;
    }
}

This approach provides type-safe method handling with built-in validation.

Why Building Without Frameworks Matters

This implementation deliberately avoids MCP SDKs or frameworks to reveal important insights:

1. The Protocol is Simple

At its core, MCP is just JSON-RPC 2.0 over newline-delimited streams. No magic, no hidden complexity—just structured messages over STDIO.

2. Debugging is Straightforward

Without framework abstractions, every message is visible and every routing decision is explicit. Problems can be traced directly to protocol-level issues.

3. Portability is Maximized

This implementation could be ported to any language that can read stdin and write stdout—no framework dependencies to worry about.

4. Understanding is Complete

By implementing from scratch, developers gain deep understanding of:

• How capability negotiation works

• Why message IDs matter

• How bidirectional communication flows

• What makes MCP transport-agnostic

5. Performance is Transparent

Without framework overhead, the performance characteristics are clear:

• Message parsing time = JSON deserialization

• Routing overhead = switch statement

• I/O latency = STDIO buffering

Conclusion: The Elegance of STDIO-Based Protocols

This deep dive into a framework-free MCP implementation reveals the elegant simplicity at the protocol’s heart. By using STDIO as the transport layer, MCP achieves:

• Universal compatibility: Any language that can read and write text can implement MCP

• Process isolation: Natural security boundaries without complex authentication

• Debugging transparency: Every message is visible and reproducible

• Deployment simplicity: No ports, no certificates, no network configuration

The implementation demonstrates that building AI-integrated tools doesn’t require complex frameworks or abstractions. At its core, MCP is about structured communication—JSON messages flowing over STDIO streams, enabling AI systems to discover and use tools in a standardized way.

By understanding these fundamentals through a bare-metal implementation, developers gain the knowledge to:

• Build MCP servers in any language or environment

• Debug protocol issues at the message level

• Optimize performance by understanding the actual costs

• Extend the protocol while maintaining compatibility

As AI continues to evolve, the ability to create tools that AI can understand and use becomes increasingly valuable. This implementation shows that such integration doesn’t require magic—just careful attention to protocol details and disciplined STDIO handling.

The Model Context Protocol’s choice of STDIO as its primary transport isn’t just a technical decision—it’s a philosophical one. It says that AI-tool integration should be simple, debuggable, and accessible to everyone. By building without frameworks, we see this philosophy in action: powerful capabilities emerging from simple, well-designed primitives.

Whether you’re building the next generation of AI tools or simply understanding how AI systems communicate, the lessons from this STDIO-based implementation provide a solid foundation for creating robust, interoperable systems that bridge the gap between human intentions and machine capabilities.

Learn By Building: The Agent MCP Workshop

If you found this deep dive valuable and want to build your own MCP server from the ground up, check out the Agent MCP Workshop on GitHub. This instructor-led workshop takes you through five progressive lessons:

1. Building the Transport Layer - Create a robust STDIO communication foundation

2. Understanding the Protocol - Implement JSON-RPC message handling

3. Protocol Handshake & Routing - Build initialization and message dispatch

4. Implementing Capabilities - Add Resources, Tools, and Prompts

5. Agent Integration - Connect your MCP server with AI agents

The workshop provides hands-on experience with the exact code examined in this article, along with exercises, debugging techniques, and best practices for production deployment. Whether you’re learning solo or in a group setting, the workshop materials offer a structured path to MCP mastery.

Start building your own AI-integrated tools today: github.com/David-Parry/agent-mcp-workshop

Originally published at Foojay.io on July 2025.

And now, let’s review some of the other cool things that appeared on Foojay.io last month…

Foojay Podcast #89: Quarkus and Agentic Commerce

The latest Foojay Podcast episode features Frank Delporte discussing Quarkus with Michal Maléř and Holly Cummins, and the conversation goes in some unexpected directions.

Sure, they cover the expected ground - how Quarkus compares to other frameworks, the build-time optimization vs AOT vs JIT debate, and the impact on cloud costs (both financial and ecological). But things get really interesting when they dive into “chain transactions” and how nano businesses could serve as a model for paying content creators through standards like x402 and ERC-8004.

The discussion on whether MCP could serve as a content distribution mechanism (with Quarkus, naturally) at the 46-minute mark is worth the listen alone, especially in early 2026 where world visibly got crazy. It’s one of those podcasts that starts technical and ends up philosophical - in the best possible way.

The Ultimate 10 Years Java Garbage Collection Guide (2016–2026)

Alexius Dionysius Diakogiannis in The Ultimate 10 Years Java Garbage Collection Guide (2016–2026) has put together what might be the definitive guide to choosing the right garbage collector for your workload.

And yes, the title is ambitious, but the content delivers.

For years, the standard advice was “G1 is always best.” With Generational ZGC arriving in JDK 21-25, that’s no longer true. Generational ZGC achieves roughly 10% better throughput than its single-generation predecessor and prevents the allocation stalls that plagued earlier versions. The guide provides specific recommendations for different workload types - microservices, legacy JEE, stateful UI applications, and data-intensive batch processing.

If you’re still running with default GC settings in production (don’t worry, no judgment here 😉), this is your weekend reading.

Java on Single Board Computers: x86 vs ARM vs RISC-V

Frank Delporte is not only a Java Champion and Foojay Podcast host, but also an author of Getting Started with Java on the Raspberry Pi is expanding beyond his Raspberry Pi comfort zone in 2026. Java on Single Board Computers: x86 vs ARM vs RISC-V, his comparison of x86, ARM, and RISC-V architectures for Java development is exactly what you’d expect from Frank - thorough, practical, and full of the kind of details only someone who actually uses these boards would know.

The RISC-V section is particularly interesting for those of us watching that ecosystem mature. The good news: Java officially supports RISC-V with the OpenJDK RISC-V Port. The less good news: early implementations like the Kylin X1 are still 2-7x slower than Raspberry Pi 5 in benchmarks. But hey, RISC-V is open source and licensing-fee-free, so expect rapid improvement in the tooling.

Especially as it’s important part of the recent trade conflict.

Command Completion: IntelliJ IDEA with Less Shortcuts

How many shortcuts can you remember? Three? Five? 👩🏻💻 Marit van Dijk , Java Champion and Developer Advocate at JetBrains , asks the question we’ve all been afraid to answer - even before ourselves.

The new command completion feature in IntelliJ IDEA (..) lets you discover and execute IDE actions right from your editor - no shortcut memorization required. Type two dots after any symbol, and you’ll see all relevant commands for your current context. Want to rename a class but forgot Shift+F6? Just type .. and filter for rename. Need to add JavaDoc? you know the drill - ..add javadoc. Some commands even have aliases, so ..change name works just as well.

It’s one of those features that sounds minor but actually changes how you interact with the IDE. The article walks through fixing errors, performing file-level actions, refactoring, and navigation - all without leaving the flow of coding.

Why is My Talk Selected? Reflections from a Program Committee Reviewer

And finally, something for those of you eyeing the CFP deadlines on your calendar. Soham Dasgupta, drawing on his experience as a reviewer for Voxxed Days Amsterdam and organizer of internal meetups, shares the criteria that guide talk selection. If you’ve ever wondered why some submissions get accepted while others don’t (and you’ve definitely wondered), this explains the decision-making process.

The article breaks down selection criteria into two categories: speaker/talk-related reasons (clarity, originality, relevance, speaker credibility) and organization/program-related reasons (diversity, schedule balance, avoiding duplication). The most valuable part: understanding that rejection isn’t personal - it’s often about schedule fit, topic balance, or simply too many good submissions.

The honest admission that “as reviewers, we actively welcome a percentage of new speakers” is refreshing. The advice to share your story - not just technology features - resonates with what I’ve seen work at conferences. And the practical tip about including a recording link with your submission? Worth the read for that alone.

BTW: Big thanks to David Parry for the guest feature this month. It was great to see you on Jfokus man!

BTW2: IntelliJ IDEA Conf 2026 is coming! March 26-27, free virtual event - speakers are already published, schedule drops the week of Feb 9th.

List is enormous, just to mention Josh Long Ana-Maria Mihalceanu Ivar Grimstad Thomas Wuerthinger, Viktor Gamov Mark Pollack... the list is just to long, and that’s not including the team from JetBrains as a hosts and speakers: 👩🏻‍💻 Marit van Dijk Arun Gupta 👓 Anton Arhipov Evgeny Borisov and Siva Katamreddy.

BTW3: KotlinConf 2026 is also on the horizon - more information soon! 👉 kotlinconf.com

BTW4: A bit of selfplug at the end:

⭐⭐⭐⭐ New chapters of Vibe Engineering: Best Practices, Mistakes and Tradeoffs just dropped on Manning Publications Co. MEAP ⭐⭐⭐⭐

What’s in the new content? The things nobody seems to talk about - methodological approach and performance engineering techniques. No “10 magical prompts”, but also no “I let 🦞 rewrite my entire codebase in the weekend” - just methodology you can actually use regardless of which model is trending this week.

The core idea: engineering discipline comes from process, not from the model. Every technique comes from a year of daily testing with our team at VirtusLab - we stress-test every new trend (and eat the failures) so you don’t have to.

👉 hubs.la/Q03XhKmG0 🎟️ Save 40% with code: WATCHLELEK240

Also: we’re publishing this issue a week earlier than usual, because I’m on vacation next one 😉. To make up for it, this edition is a combined one (December + January). December edition didn’t happened due to holidays - so we’ll catch up with one solid package.

1. Missed in December / January

Let’s start with a small celebration - JetBrains is marking an extraordinary milestone: IntelliJ IDEA turns 25 this year! 🎉 The first release of the IDE appeared in January 2001 and was one of the very first Java development environments to offer advanced code navigation and built-in refactoring capabilities. I have to admit, it never occurred to me that it’s only five years younger than Java itself 😃.

To celebrate the anniversary, JetBrains prepared a special page with a game in which Runzo - the mascot of the Run button - breaks free from the IDE and travels across the IntelliJ IDEA universe.

PS: The game was created by Alexander Chatzizacharias - if you’ve never seen his talks, make sure to catch up. Pure joy and true hacker energy.

InfoQ has released the Java Trends Report 2025, and it’s packed with insights.

In the 2024 edition, you could still feel the post–AI-carnival sobriety (“wild west”, less of a hammer-for-everything mindset, more common sense).

In 2025, AI on the JVM looks less like an exotic animal in a zoo and more like a new neighbor in the apartment block: it has its own frameworks and libraries (the report mentions, among others, Spring AI, LangChain4j, and friends), so the conversation shifts from “should we?” to “how do we deliver this sensibly?”.

The second big change is modernization - in 2025 it’s no longer a side note but a full-fledged program, with automation front and center. The report explicitly points to OpenRewrite is there as the dominant tool for industrial-scale upgrades and refactoring, which sounds like another step toward a world where we stop doing “heroic migrations” and start simply… running them in the pipeline. And when it comes to Java versions: 2024 liked to count adoption (17, 11, 8… and a cautious approach to 21), while 2025 leans harder into the “baseline” narrative - Java 17+ as the new normal, with Java 25 as a symbolic anchor: “modernity isn’t a hobby, it’s the standard.”

As you see, there is far more different changes - personally, I’m still eager to see Java on Arm and CRaC moved to Early Majority, but we probably need to wait till the 2026.

Here we go again - not a repeat of Log4Shell, but still serious. On December 19, 2025, a new vulnerability (CVE-2025-68161) was disclosed in Apache Log4j Core, affecting versions from 2.0-beta9 up to 2.25.2. December once again reminded us that security-related technical debt never truly disappears, even four years after the original Log4Shell incident.

The issue resides in the SocketAppender component, which sends logs over the network to a remote log server. Affected versions did not properly enforce TLS hostname verification, meaning the client could accept any certificate issued by a trusted CA - even for the wrong domain. This opens the door to Man-in-the-Middle attacks and potential leakage of sensitive data often found in logs (tokens, personal data, SQL fragments).

The fix is straightforward: upgrade to Log4j 2.25.3, which restores strict hostname verification. As always, teams should urgently scan not only direct but also transitive dependencies - Log4j has a habit of hiding where you least expect it.

Adam Bien AirHacks delivers as always, but this episode is a real gem. In the latest AirHacks.fm conversation, Thomas Wuerthinger walks through the current direction and future of GraalVM - from changes in release cadence and a focus on Java LTS versions only, through the growing importance of Python and AI, to the increasingly tight integration with Oracle Database.

The discussion spans Oracle Multilingual Engine, running Python and JavaScript directly inside the database, native images as stored procedures, database-native serverless and scale-to-zero, CRaC-like application snapshotting in user space, WebAssembly as a deployment target for edge functions, and very concrete insights into why native image matters beyond startup time...

Together, it paints a picture of GraalVM evolving from a startup-time optimization tool into a foundational platform for running business logic closer to the data. And taking into account recent lack of insight into project, such a peek into the belly of the beast is always interesting.

An important update for the unit testing community: Tim van der Lippe has announced that he is stepping down as a maintainer of Mockito after a decade of work. His departure is a loud warning signal about the relationship between platform developers and library maintainers in the Java ecosystem.

At the technical core of the issue are changes introduced in OpenJDK starting with Java 22, related to dynamic JVM agent attachment. Mockito relies on deep bytecode manipulation at runtime to mock final classes, static methods, or private methods - historically achieved via dynamically attaching a Java agent. In the name of security (“Integrity by Default”), the JVM now requires explicit user opt-in for such behavior. While the goal is reasonable from a platform security perspective, Tim argues that the changes were effectively a “done deal,” introduced without providing alternative APIs that would allow library authors to achieve the same goals in a supported, safe way.

Tim’s exit - and his move to the Servo project written in Rust - highlights a deeper, systemic problem. Libraries like Mockito are critical infrastructure for millions of Java tests. When platform-level decisions force hundreds of hours of unpaid work onto volunteer maintainers, the model starts to break down. The ecosystem doesn’t just lose code - it loses hard-won expertise. The fact that a maintainer of Tim’s caliber is seeking “joy in programming” outside the JVM should be a moment of reflection for Java’s architects - even if it’s very hard to argue with their argumentation about cleaning up the platform.

And last but not least in that section... we started with the celebration, we will end with a celebration: We have another Polish Java Champion - Grzegorz Piwowarek!

Grzegorz is the leader of Warsaw Java User Group, a program committee member of JDD and 4Developers, author of 4comprehension.com - and also the current maintainer of Vavr. Over the years, he has delivered 150+ conference talks and 85+ hands-on workshops, shaping both the Polish and international Java communities.

A well-deserved recognition - and a perfect segue into the next section.

We are starting Release Radar.

2. Release Radar

Vavr 0.11.0

The segue was a natural one: the library now maintained by Grzegorz, Vavr, has just released Vavr 0.11.0 - its first minor release in several years.

For these who do not remember - Vavr is a non-commercial functional library for Java 8+, designed to reduce boilerplate through immutable collections, pattern matching, and monadic types such as Option, Try, and Either.

The most notable addition is a lazy for-comprehension API that accepts functions instead of eagerly evaluated values, enabling more efficient operation chaining. Vavr now also integrates JSpecify annotations, improving null-safety support in IDEs and static analysis tools. Future cancellation has been refined as well: tasks that have not yet started can now be cancelled. The release also introduces several new APIs, including Either/Validation.cond(), Value.mapTo(U), Value.mapToVoid(), and Try.toEither(Throwable -> L).

From here, project is shifting focus toward Vavr 1.0.0, which is expected to bring a significant increase in the required Java version.

More details are available in the Release Notes.

Kotlin 2.3.0

JetBrains has released Kotlin 2.3.0 with a rich set of improvements across the language and its ecosystems. At the language level, more features are now stable and enabled by default, a checker for unused return values has been added, and explicit backing fields provide finer control over properties. Kotlin/JVM now adds support for Java 25.

Meanwhile, Kotlin/Native improves interoperability through Swift export and delivers faster release build times. Kotlin/Wasm gains fully qualified names and a new exception-handling proposal enabled by default, along with compact Latin-1 string storage.

Kotlin/JS introduces experimental export of suspend functions, a new representation for LongArray, and unified access to companion objects. Gradle 9.0 is now fully supported, together with a new API for registering generated sources. The standard library brings a stable time-measurement API and improved UUID generation and parsing, while the Compose compiler adds stack traces for minified Android applications.

More details are available in the Release Notes and video with new features demoed:

IntelliJ IDEA 2025.3

And now it’s time for the birthday star!

As I already mentioned in my year-in-review (this is what happens when there’s no Rest of the Story edition in December), JetBrains has introduced a fundamental change to its distribution model: IntelliJ IDEA 2025.3 is now a unified product, with no separate Community and Ultimate editions. This is a real shift for developers who previously had to choose between a free but limited version and a paid, full-featured one. All features from the former Community edition remain free, and JetBrains has additionally made basic support for Spring, Jakarta EE, and template engines like Thymeleaf available at no cost.

This change means that even small teams and individual developers can now use professional tools for working with popular enterprise frameworks without extra expense. JetBrains is clearly betting on a model where advanced AI features and additional integrations remain paid, while a solid, high-quality foundation for everyday development is accessible to everyone.

Two feature highlights worth calling out in IntelliJ IDEA 2025.3 are the open, integrated AI experience and the new multi-agent workflow. JetBrains AI is no longer a black box: you can now see and track your AI credits directly inside the IDE, use multiple agents from a single chat interface, and work with both JetBrains’ own Junie and the natively integrated Claude Agent. On top of that, Bring Your Own Key (BYOK) lets you connect your own OpenAI, Anthropic, or OpenAI-compatible local models, giving teams far more control over providers, costs, and data flows.

Another notable feature is command completion, which brings IDE actions directly into code completion. Typing . now shows not only code and postfix completions, but also relevant actions, while .. filters the list to actions only. You can preview exactly what an action will do before applying it, reducing context switches and shortcut hunting. It’s a small change with a big impact on flow - making powerful IDE features feel like a natural extension of typing code rather than something hidden behind menus or keymaps.

More details are available on the What’s New page. And here you can find video where 👩🏻💻 Marit van Dijk, Marco Behler, 👓 Anton Arhipov and Siva Prasad Reddy K present new editor capabilities.

WildFly 39

WildFly 39 brings improvements in clustering, an area that matters whenever you run applications on more than one node. A key part of this is better TLS support for JGroups - a Java library used by WildFly (and many other systems) to handle node discovery, group membership, and reliable message exchange between servers in a cluster. With this release, TLS can now be configured directly for TCP-based JGroups transports, making it easier to secure inter-node communication and potentially replace older encryption setups such as ASYM_ENCRYPT with the simpler AUTH mechanism.

WildFly 39 also adds time-based HTTP session eviction, giving administrators more flexible control over memory usage when session data sizes vary widely. Alongside these features, the release updates core components and fixes multiple security issues, enforces stricter HTTP compliance by always requiring the Host header for HTTP/1.1+ requests, and introduces a 1GB limit for deployments uploaded over HTTP.

Full details are available in the Release Notes.

JobRunr 8.4

JobRunr 8.4 continues its Kotlin-first push with improved Bazel compatibility, auto-configured serialization, and full support for Micronaut 4.10.

JobRunr is a background job processing library for Java and Kotlin that lets you define and run reliable, persistent background tasks (such as emails, data processing, or scheduled work) using plain Java or Kotlin code, without requiring a separate queue system. In this release, Kotlin lambdas compiled with Bazel’s rules_kotlin now work seamlessly, fixing long-standing NullPointerException issues when enqueueing Kotlin lambdas. Serialization gets smarter as well: KotlinxSerializationJsonMapper is automatically detected and configured when kotlinx-serialization-json is present on the classpath, while Jackson3JsonMapper now supports custom polymorphic type validators for improved security.

JobRunr Pro adds flexible license key loading, configurable graceful shutdown when the storage layer becomes unavailable, and dashboard improvements like logout and exception-type filtering.

More details are available in the Release Notes.

Gradle 9.3.0

Gradle 9.3.0 is a release that significantly improves the developer experience, especially around testing.

The headline feature is a completely redesigned HTML test report: instead of a flat list of tests, it now presents a hierarchical structure that mirrors your actual code organization.

Nested tests appear nested, parameterized tests are grouped under their defining method, and test suites clearly contain the classes they execute. Even more importantly, test output (stdout/stderr) is no longer merged at the class level - you can now see exactly which test produced which log line. This may sound minor, but in practice it means no more digging through hundreds of lines of output asking “which test actually failed?”. For builds aggregating tests from multiple subprojects, the report now also handles overlapping names correctly and shows each source as a separate tab.

For build and plugin authors, there are several practical improvements as well. The new AttributeContainer.named() API allows for more concise configuration of dependency resolution attributes, while TestKit gains getOutputReader(), enabling streaming of test output instead of loading massive logs into memory during integration tests. The release also fixes two security vulnerabilities related to dependency repositories: previously, repositories were not reliably disabled after hostname or timeout errors, potentially exposing builds to malicious artifacts. Repository disabling is now stricter, and all Gradle distributions are shipped with PGP signatures (.asc), aligning with broader efforts to improve supply chain integrity.

More details are available in the Release Notes.

Spock 2.4

Spock Framework 2.4 - one of the most popular mock tests frameworks - is a long-awaited version which arrives more than three years after 2.3 (September 2022) and its most important change is support for Groovy 5.0, which is a major milestone for the ecosystem. Groovy 5 requires Java 11+ and introduces its own breaking changes, forcing substantial internal refactoring in Spock (the _ identifier becoming a reserved keyword in Java 9+ was a particularly painful example). At the same time, Spock continues to support Groovy 2.5, 3.0, 4.0, and now 5.0, allowing teams to upgrade at their own pace.

More details are available in the Release Notes.

Spring gRPC 1.0.0 GA

Spring gRPC 1.0.0 is the first official, fully supported integration of gRPC into the Spring ecosystem, with full compatibility for Spring Boot 4 and Spring Framework 7. One important architectural decision stands out: the autoconfiguration and starter dependencies are deprecated right at the 1.0 release. This is intentional - Spring gRPC 1.1 (targeting Spring Boot 4.1) will move all autoconfiguration directly into Spring Boot itself. In practice, Spring gRPC 1.0 acts as a transitional release, giving teams time to upgrade while signaling that gRPC support will soon be a first-class, built-in Spring Boot feature. The framework requires Java 17 as a baseline and already supports Java 25 as the latest LTS, with JSpecify annotations aligning it with Spring Framework 7’s stronger focus on null-safety and Kotlin-friendly APIs.

From a developer experience perspective, the key theme is simplicity. To get started, you add the spring-grpc-spring-boot-starter, define your .proto file, and implement a Spring @Service that extends the generated ImplBase (or implements BindableService). The gRPC server starts automatically on port 9090 - no manual wiring required. This is a major improvement over older community solutions (such as the now-abandoned LogNet starter), which required extensive configuration. Out of the box, you get integration with Spring Security (OAuth2, TLS/mTLS), Micrometer for observability, and Spring Boot DevTools for hot reload.

Spring Tools 5.0.0

Spring Tools 5.0.0 is also an important update. The headline feature is Logical Structure View - a conceptual project view that organizes code by Spring stereotypes (controllers, services, repositories, entities) instead of folders and packages. This reflects how developers actually reason about Spring architectures and was designed in collaboration with Spring Modulith and jMolecules. The view supports custom stereotypes via META-INF/jmolecules-stereotypes.json or @Stereotype annotations and automatically aligns with Spring Modulith when present. On top of that, Spring Tools 5 delivers deep support for Spring Boot 4 and Spring Framework 7: API versioning with CodeLens summaries and validation, functional bean definitions via the new BeanRegistrar API, AOT repositories in Spring Data with SQL visualization, and automatic JSpecify-based null-safety analysis.

The second major pillar of this release is AI-native tooling. Spring Tools 5 integrates with Cursor and Copilot, but the most interesting addition is an embedded Model Context Protocol (MCP) server. This experimental feature allows AI coding assistants - including CLI-based tools like Claude Code - to access rich, Spring-specific context such as resolved classpaths, Spring Boot versions, bean definitions, dependencies, and architectural stereotypes. The MCP server runs inside Spring Tools and works only with an open project, but in return enables far more precise and architecture-aware AI assistance. The release also introduces AI-powered code actions for explaining SQL queries, SpEL expressions, pointcuts, and converting functional web routes.

More details are available in the Release Notes.

Hibernate ORM 7.2.0

Hibernate ORM 7.2.0 is headlined by experimental support for reading data from read-only replicas of the primary database. The release adds the new @EmbeddedTable annotation, significantly simplifying the mapping of embedded values to separate tables and reducing the need for verbose @AttributeOverride and @AssociationOverride configurations.

It also introduces FindMultipleOption, filling a long-standing gap in Session#findMultiple configuration, enables creation of child StatelessSession instances that share transactional context with a parent, expands the hibernate-vector module with SQL Server support, and adds regular expression support in HQL along with further enhancements to the SchemaManager.

More details are available in the Release Notes.

TornadoVM 2.x - GPU acceleration for Java, now more practical

TornadoVM 2.x represents a major step toward making GPU and accelerator offloading practical for JVM applications. Whereas earlier versions of TornadoVM were primarily research-oriented, 2.0 and subsequent 2.1+ releases usher in a more production-ready SDK with prebuilt binaries and easier integration into Java projects (available via standard dependencies and soon also via SDKMAN!) instead of requiring building from source.

The core idea remains the same: TornadoVM acts as a plugin for OpenJDK/GraalVM that compiles and offloads parts of your Java code to heterogeneous hardware like dedicated GPUs, integrated GPUs, FPGAs, and multi-core CPUs - targeting backends such as OpenCL, NVIDIA PTX, and SPIR-V - without rewriting in CUDA or native languages. It accomplishes this by generating accelerator-friendly kernels from annotated Java code, managing data movement between the JVM and device memory, and handling execution on the target hardware.

The 2.x series introduces important performance-oriented features: native support for INT8 data types on PTX/OpenCL (critical for quantized machine-learning workloads), FP32↔FP16 conversion across all backends for efficient half-precision computation, zero-copy native arrays that eliminate host↔device transfer overhead, and support for half-float operations such as Q8_0 matrices that boost throughput in ML kernels like those used in LLM inference.

Subsequent releases (e.g., 2.1.0) include enhancements such as improved FP16 handling and expanded array support. TornadoVM keeps two complementary APIs: a high-level Loop Parallel API using annotations like @Parallel and @Reduce for data parallelism, and a lower-level Kernel API with explicit control over threads, local memory, and barriers for experienced accelerator programmers - all while preserving multi-vendor portability.

TornadoInsight

Tooling around the SDK is improving too, with IDE support. TornadoInsight is an IntelliJ IDEA plugin developed alongside TornadoVM 2.x that fundamentally improves the developer experience of GPU acceleration in Java by making what used to be opaque and log-driven fully visible inside the IDE. Instead of manually inspecting kernel dumps and thread logs, developers get a graphical TaskGraph visualization showing how Java code is compiled into GPU kernels, how tasks depend on each other, where host <-> device memory transfers occur, and which phases are the real performance bottlenecks.

The plugin integrates with the IntelliJ profiler to break execution down into compilation time, memory transfer overhead, and actual kernel runtime, and adds navigation between Java source and generated GPU code, syntax highlighting for TornadoVM’s intermediate bytecode, and side-by-side device comparison across different GPUs or backends.

For teams optimizing compute-heavy workloads or porting CUDA/OpenCL code to TornadoVM, TornadoInsight goal is to turn GPU acceleration from trial-and-error into an inspectable, iterative workflow.

LangChain4j 1.10.0

The headline feature of LangChain4j 1.10.0 is the Model Catalog, a unified discovery and configuration layer for providers like Anthropic, Gemini, OpenAI, and Mistral, allowing developers to reference models by semantic names instead of hard-coding specific model IDs - and enabling automatic upgrades or graceful fallbacks to cheaper models without redeploying applications. The Anthropic integration received a significant upgrade with structured outputs (direct JSON-to-POJO deserialization via JSON Schema), strictTools mode to reduce tool-calling hallucinations, access to raw HTTP/SSE events for advanced observability, and native PDF input via URL.

On the production side, new AgentListener and AgentMonitor APIs provide fine-grained visibility into agent reasoning steps, tool usage, latency, and token consumption, which is critical for debugging and cost control. AI Services now support per-call tuning via ChatRequestParameters, MCP support has been hardened for real-world networking scenarios, OpenAI integration adds native transcription support, Gemini improves schema handling and batch processing, and the deprecated GitHub Models module signals a pragmatic focus on mainstream providers.

Full details are available in the Release Notes.

OmniFaces 5.0

Anyone remember what OmniFaces actually is? 😉 If you’ve ever built a serious Java Server Faces application (I’m so sorry), the answer comes back fast - and OmniFaces 5.0 - set of JSF components - proves it’s very much alive. Released in December 2025, this major version cleans up years of legacy decisions and aligns the project with Jakarta EE 11, raising the baseline to Java 17 and Faces 4.1.

The most visible change is the switch to a URN-based XML namespace (xmlns:o=”omnifaces”), merging the old UI and functions namespaces into one (with full backward compatibility across the 5.x line). All APIs deprecated in 4.x were physically removed, several components were renamed for consistency with Jakarta Faces, resource handling was modernized, and bundled JavaScript was migrated to TypeScript.

At the same time, OmniFaces adds small but practical new APIs (like HTML5 doctype detection and safe HTTP response resets) and continues to support cloud-native deployments via a Quarkus extension - a reminder that despite its “legacy” reputation, the JSF ecosystem still has an active community solving real enterprise problems (so sorry, once again).

More details are available in the Release Notes.

3. GitHub All-Stars

Juicemacs

Juicemacs is a project by Kana (gudzpoz) that’s both crazy and brilliant at the same time - a reimplementation of the legendary Emacs editor in Java, built on top of the Graal Truffle framework. Thanks to Truffle, Emacs Lisp (ELisp) code can be JIT-compiled to native machine code, potentially delivering performance that classic C-based Emacs can’t reach (due to Lisp evaluator, not C).

Juicemacs currently ships with two working interpreters (one AST-based and one bytecode-based) and enough built-in functionality to support pdump. It’s a fascinating demonstration of GraalVM’s polyglot power - running languages like ELisp on a shared runtime with full interoperability. The author presented the project at EmacsConf 2025, showcasing experimental optimizations such as constant folding for stable global variables.

BTW: There are two fantastic blog[1] posts[2] about creating the projects. I will play a bit with this and probably return to the topic in one of the future editions.

Annote

Staying in the Lisp regions - Annote is… an experiment you have to see to believe.

Annote is an interpreter that executes Java annotations as a programming language - variables, conditionals, loops, I/O, arithmetic, and method calls, all expressed via @Var, @If, @Loop, @Print, and similar annotations. Just... take a look.

Java annotations were designed for metadata. Spring uses them for dependency injection. Lombok for code generation. JPA for ORM mapping. Annote uses them to write entire programs. Is it practical? Absolutely not. Is it a fascinating experiment that exposes the limits of Java’s annotation system? Definitely.

But in positive sense! I think we just found 2026’s edition of Annotatomania.

MIT licensed - because even cursed code deserves freedom.

BTW: I love how this repository was weaponized in ongoing war with Skynet 😀

Hardwood

Hardwood is a minimalist implementation of Apache Parquet for Java, created by Gunnar Morling (yeah, the one behind 1BRC). It provides an API compatible with parquet-java, enabling migration with minimal code changes.

Parquet is a columnar file format for tabular data, optimized for analytics by enabling efficient storage, compression, and fast reads of only the needed columns (e.g. in Spark or BigQuery).

In benchmark tests on 44 million rows, Hardwood processes data in about 19 seconds, compared to 84 seconds for parquet-java. It achieves this by parallelizing column processing across CPU cores. For projects dealing with large Parquet datasets, this is a very compelling alternative.

jMigrate

jMigrate is a small, lightweight database schema migration library positioned as an alternative to Flyway and Liquibase for projects that need less overhead. A single call to JMigrate.migrate() at application startup is enough to apply all pending migrations.

jMigrate compares the current set of migration scripts with the state recorded in database tables. If the state is “dirty,” it automatically rolls back to the last clean point and reapplies subsequent migrations. Production safety is handled via the allowExecutingDownScripts flag - recommended to be set to false in production to prevent accidental data loss.

zone-scope

zone-scope is a real-time audio visualization tool written in Java/Swing. It supports live audio capture (via JACK or JavaSound), loading audio files with precomputed FFT, and a spectrometer with adjustable frequency response (20 Hz–14 kHz) and a logarithmic frequency scale.

Its standout feature is a zero-copy real-time processing path — allocation-free audio callbacks suitable for continuous visualization. The project requires Java 21+ and is part of the larger JudahZone ecosystem for live looping. It’s a strong example that modern Java is perfectly capable of low-latency, multimedia-heavy workloads as well.

New year, new plans, new promises we’ll look back on in twelve months with a mixture of nostalgia and disappointment.

But rather than dwelling too much on those New Year’s resolutions - there’ll be plenty of opportunity for that - let’s take a look at what OpenJDK teams themselves are saying about their plans for 2026.

OpenJDK Plans for 2026 - Valhalla Getting Closer, Amber Not Slowing Down, Loom Nearly Complete

I have to admit: Nicolai Parlog from Oracle gave me a pleasant surprise. His New Year’s episode of Inside Java Newscast extracted concrete details from people working on individual projects. An “anonymous source” (whose identity anyone who’s ever heard Brian Goetz will immediately guess) dropped some bombs worth discussing.

Valhalla is targeting JDK 28. This is probably the most important piece of news. Our Anonymous Source revealed that value types won’t make it into JDK 27 - but not because they aren’t ready.

JDK 27 forks in June, so mainline will switch to 28 then - with room for JEP 401. After value types, nullness markers, array improvements, and primitive-wrapper unification are queued up - but that’s a perspective for later releases.

Vector API is waiting for Valhalla. JDK 26 will see its eleventh (!) incubation - and it’ll stay that way until value types land in mainline. When that happens, the implementation will be rewritten and the API moved from jdk.incubator.vector to the proper java package.

Leyden - AOT code compilation. The AOT cache will contain not just loaded classes and method profiles, but compiled machine code as well. The runtime will be able to pull optimized code straight from the cache, dramatically reducing warmup time.

Structured Concurrency nearing finalization. After the revamp in JDK 25, the API will go through preview with minimal changes - Nikolai rates the chances of finalization this year as good. This is the last piece of the big Project Loom picture (though some would like to see a bit of “scope creep” here - in the positive way - which we’ll get to shortly).

Amber - constant patterns and pattern assignment. The team is “knee-deep in the second phase of pattern matching.” Two features are mature enough that JEPs may appear this year. We’ll examine all of this ourselves in a moment since the details from the mailing lists are very interesting, but apparently ideas for generalizing records and pattern matching to classes and interfaces are popping up on amber-spec-experts. So “things are happening.”

Babylon preparing code reflection incubation. The technology allowing frameworks to reflect over code in methods and lambdas is developing well—we should hear more this year. I’m personally eager for any announcements related to GPU support.

That’s the official plans. But as usual, the most interesting things happen at the margins—in experimental branches and mailing list discussions. And that’s exactly where Valhalla is showing that value types are just the beginning of a much more ambitious story.

Type Classes - Valhalla experiments with the next step

Maurizio Cimadamore announced on the valhalla-dev list the publication of an experimental type classes prototype - a mechanism Brian Goetz presented at JVMLS 2025 in his talk Growing the Java Language. The code landed in a new type-classes branch in the Valhalla repository.

What problem do type classes solve? Today in Java, you can’t write generic mathematical code that works on int, BigDecimal, and a hypothetical Float16 alike. Interfaces require types to explicitly implement them - you can’t say Integer implements Addable without modifying the Integer class. Type classes (known from Haskell, appearing as traits in Rust) invert this relationship: instead of requiring implementation in the class, you provide an external “witness” that says “here’s how to add values of type X.” Witnesses can be defined for any type, even someone else’s.

record MyInt(int x) { }

interface Sum<X> {
    X zero();
    X add(X a, X b);
}

__witness Sum<MyInt> SUM_MYINT = new Sum<>() {
    MyInt zero() { return new MyInt(0); }
    MyInt add(MyInt a, MyInt b) { return new MyInt(a.x + b.x); }
};

// Usage:
Sum<MyInt> sum = Sum<MyInt>.__witness;
MyInt zero = sum.zero();
MyInt one = new MyInt(1);
assert sum.add(zero, one).equals(one);

In this prototype, you can define a type class and a witness for a specific type. For example, here’s how an addition type class (Sum) and its witness for a value class MyInt are defined.

• Sum<X> is a generic interface representing a type class for addition.

• __witness defines a witness for how MyInt implements that type class externally.

• The witness can then be looked up and used at runtime.

This prototype enables external definitions of operations for types without modifying those types themselves, addressing a long-standing limitation in Java: today it’s impossible to write truly generic mathematical code that works uniformly across primitives like int, boxed types such as BigDecimal, and custom numeric or value types, because interfaces require the types to explicitly implement them. Type classes invert this relationship by allowing behavior to be attached externally via so-called “witnesses,” making it possible to state “here’s how type X does addition” without editing X at all.

Goetz explained the broader vision at JVMLS: type classes are meant to enable operator overloading for value types, collection literals, or new numeric types with full support for +, -, * - but without the operator hell known from C++, since they’d be limited to value classes only.

Maurizio is very clear on one point, though: this is purely a space for experimentation, not a proposal for inclusion in the Java platform, and any JEP is still a long way off.

With Valhalla, as ever, patience is part of the lesson. However, they have even more under they sleeve now!

Null Checks get concrete - The “Bang World” Prototype

Daniel Smith announced on valhalla-spec-experts another prototype branch worth watching: bworld (short for “bang world”). This one tackles the long-awaited nullness markers - specifically, the runtime enforcement side of making ! actually mean something.

The idea is straightforward: mark types with ! to indicate a non-null barrier, and have the JVM enforce it. You’ll be able to use ! on field types, local variables, method parameters, return types, casts, instanceof, and array element types. And crucially - this isn’t limited to value classes. Any reference type can be marked.

What happens at runtime? The compiler generates calls to a new java.lang.runtime.Checks API (deliberately not Objects.requireNonNull - they want the JVM to have freedom to treat these checks specially). What those it mean in practice?

• A cast to String! will throw if you pass null

• A field declared as String! name must be initialized before the super() call.

• Arrays created with new Foo![]{a, b, c} will reject null writes dynamically.

Daniel notes that current implementation only fully supports runtime checks for value-class-typed fields and arrays - other reference types will get the metadata in the class file, but enforcement is coming later.

The prototype also includes optional lint warnings for suspicious patterns - like assigning null literals to ! targets or removing ! markers when overriding methods. But the most interesting bit is “use-site checks”: the compiler can insert null checks when calling methods from untrusted binaries! This neatly exposes the real problem: not greenfield code, but millions of libraries that were written when null markers weren’t even imaginable.

That’s the real challenge: how to introduce null-safety into a 30-year-old ecosystem gradually, without breaking the world? But as Daniel puts it:

This is not the final version of the feature... it’s a snapshot. But we’ve been wanting something concrete that we could play with.

The Kotlin crowd will feel right at home, except for one crucial difference: Kotlin’s null-safety is purely a compiler-land, erased at runtime. Java is building actual JVM enforcement. Slower to arrive, but when a String! field says “never null,” the runtime will back that promise up.

Ephemeral Threads - Clojure knocks on Project Loom’s Door “With a Request”

Mama, take this badge off of me
I can’t use it anymore
It’s gettin’ dark, too dark for me to see
I feel like I’m knockin’ on heaven’s door

Since Structured Concurrency is approaching finalization, can Project Loom be considered “finished”? The community has a different opinion. A heated discussion (30+ emails in a week) erupted on the loom-dev list, initiated by Alex Miller from the Clojure team.

The topic? So-called “ephemeral threads”- threads that can be garbage collected before they finish their work. Sounds like heresy in the Java world, where for 30 years an iron rule has applied: threads are GC roots and live until they complete their work. But for the Clojure community, this has been daily bread for over a decade.

What’s the deal? The core.async library lets you create lightweight “go blocks” that wait for data from channels. If all channels become unreachable, the block can also be collected by GC - since it would never wake up anyway. Elegant and practical when building pub/sub or pipelines.

The problem: after migrating to virtual threads, the pattern stopped working. Alan Bateman, Tech Lead of Loom, is however skeptical about the ephemeral thread concept, pointing to deeper complications: interactions with finalizers and cleaners can lead to scenarios from mildly creepy to truly terrifying.:

The possibility of GC’ing a started thread before it terminates is a scary topic. It interacts with many areas and gets really scary once you bring phantom refs, cleaners, and finalizers into the discussion.

For these so-called “forgotten sender” and “abandoned receiver” cases then it might be more interesting to see how they could be work with structured concurrency. Right now, the first API is focused on fan-out scenarios but in time we would like to have it work with channel like constructs too. I suspect this will be closer to what you are interested in.

Since JDK 21, VTs are tracked by default for diagnostic tools, so “abandoned” threads hang in memory indefinitely. The flag - Djdk.trackAllThreads=false helps, but Miller rightly asks about its future, and hears from Alan Bateman:

It's clearly an attractive nuisance right now and setting it to
false is specific to the root "thread grouping". There is some
performance work required in that area but otherwise I think it needs to
be removed.

The argument for ephemeral threads is simple: virtual threads open the door to Erlang-style architectures where lightweight processes can be abandoned when they become redundant. Miller writes directly:

Most of these constructs work as infinite loops without persistent references. You simply can’t build such libraries with the traditional approach to thread termination.

Similar voices came from other users experimenting with their own schedulers - they want to use VTs as an invisible implementation detail where the end programmer doesn’t think about threads at all.

Oracle has serious concerns, however. The main one: debugging. Viktor Klang illustrates with an example - code acquires a file descriptor, parks the thread, then releases it. If the thread gets collected while parked, the descriptor leaks without a trace.

This easily leads to problems where resources leak without any trace of who lost the - which can be nightmarish in production,

argues Klang.

Andrew Haley from Red Hat offered an interesting counterargument: if a thread is waiting on an unreachable semaphore, it will never release resources anyway - whether it takes up memory or not, the problem is the same.

There is a light at the end of the tunnel, however. Bateman suggests that cases of “abandoned” threads might play better with structured concurrency, which over time is meant to handle channel constructs as well. For Clojure, though, this means waiting - an official API for ephemeral threads probably won’t materialize, and the unofficial flag will likely disappear.

The discussion shows a broader trend: virtual threads opened Pandora’s box of new patterns that the JVM ecosystem is only beginning to explore.

Project Amber in 2026 - Pattern Assignment and Constant Patterns on the Horizon

And finally, Gavin Bierman from the Amber team shared details of plans for 2026 on the amber-spec-experts list. Beyond continuing work on Primitive Patterns (currently in preview), two new features are in the pipeline - draft JEPs should appear soon.

Pattern Assignment solves an irritating problem: sometimes we use pattern matching not because something might match, but because we want to conveniently decompose a value into parts. Today we have to write:

void process(ColorPoint cp) {
    if (cp instanceof ColorPoint(var x, var y, var c)) {
        // actual code, unnecessarily nested
    }
}

The compiler and programmer both know the pattern will always work—but the syntax forces us to pretend it’s a conditional operation. The new proposal will let you simply write:

void process(ColorPoint cp) {
    ColorPoint(var x, var y, var c) = cp;  // Pattern Assignment!
    // actual code, no nesting
}

Constant Patterns is the second proposal, simplifying a common case—matching against a specific value. Instead of:

case Point(var x, var y) when x == 0 && y == 0 -> { /* origin */ }

You’ll be able to write:

case Point(0, 0) -> { /* origin */ }

Constants (including null) will be able to appear directly as nested patterns - which will somewhat unify the awkward division between “case constants” and “case patterns.”

Finally, a small observation from my functional heart (working at the company behind Scala obliges 😉).

Looking at all these discussions, it’s hard not to notice a common denominator: functional languages and their concepts remain a key reference point for JVM evolution. Type classes are a mechanism straight from Haskell. Pattern assignment is essentially the equivalent of let with deconstruction known from ML-family languages. And ephemeral threads? It’s a request for semantics that Erlang and its descendants have treated as obvious for years.

But here’s where it gets interesting: Java isn’t so much “adopting” these concepts as conducting a sort of dialogue with them - and often says “no” or “yes, but.” Type classes will be limited to value classes to avoid “operator overloading hell.” Ephemeral threads? Bateman politely suggests that maybe structured concurrency will someday handle these cases - which in practice means “we’ll do it our way or not at all.” Pattern matching is evolving so cautiously that Scala had time to have it, stop having it (in the sense of: stop being fashionable), and have it again before Java got to constant patterns.

And this is precisely the paradox that fascinates me: paradoxically, Java has probably become the most important testing ground for functional ideas in the mainstream—not despite its conservatism, but because of it. Every feature goes through such brutal mills of backward compatibility, edge case analysis, and years of preview that what comes out the other side is... surprisingly solid. Haskell’s type classes are elegant but also notoriously difficult for the average programmer to understand. Java will probably produce something less elegant, more “corporate”- and paradoxically more useful for most developers.

There’s a certain irony in all of this: Clojure, the language that since 2007 has been proving that functional programming on the JVM is possible and practical, is now asking for functionality it implemented itself for a decade—but can’t port to virtual threads without platform support. Alex Miller knocks on the door with a proposal inspired by Erlang, and Java responds in the style of: “interesting, but have you thought about interaction with finalizers? Because we have, and we have nightmares.”

Maybe that’s exactly why this relationship works. Functional languages explore, Java stabilizes. Erlang shows that ephemeral processes are possible, Clojure proves they work in practice on the JVM, and ten years from now Java will introduce something called “Scoped Ephemeral Task Contexts” that will work with every version back to JDK 8. And mass-market enterprise will finally get a feature that functional programmers were talking about at conferences in 2015. That’s the deal—and honestly, I’m not sure there’s a better model for evolving a programming language that has to support billions of lines of production code.

PS: If you want to go deeper - see you in person 👋

If this edition resonated and you’d like to continue the conversation offline, I’ll be talking about JVM in the Age of AI at a few upcoming events:

🇸🇪 JVM in the Age of AI: 2026 Edition @ JFokus 2026

I’ll be running a 90-minute Deep Dive session focused on what really needs to happen inside the JVM for it to remain a serious platform for AI and ML - hardware, Valhalla, Babylon, GPU offloading, TornadoVM, Llama3.java, and the 2026 perspective.

I’ll also be doing two polish JUGs during one week, talking about “Agentic Systems beyond localhost” with more room for questions (and for me to fill 😁)

• 21.01 - Wrocław Java User Group (With One-and-Only Jarek Pałka)

• 22.01 - Kielce Java User Group

Love the meetup, as they give a bit more freedom to speaker - and I always like to adapt to what you want to dig into.

If you’re around: come say hi, argue, disagree, or just nerd out about the JVM.

Before we close this edition, one sad piece of news.

Scott Adams has passed away.

I know - he was a controversial figure, especially in his later years, and not everyone agreed with his views. But there’s no denying one thing: his humor was singular, sharp in a way that only engineers and office survivors truly appreciate.

For years, Dilbert perfectly captured the absurdities of corporate life, technical organizations, and management theater — and it did so with a precision that made it a recurring guest in this newsletter. Many of us laughed because it was funny; many of us winced because it was accurate.

Whatever one thinks about Scott Adams the person, Scott Adams the cartoonist shaped a generation of engineers and gave us a shared language to talk about dysfunction, nonsense, and the quiet heroism of surviving another meeting that should have been an email.

Rest in peace, Scott.

And the truth is - like year ago - I thought it would be a bit shorter... but quite a lot happened.

It took a bit since last JVM Weekly issue, so I had a lot of time… and may have overdone it a bit as original draft had 43 pages (and that’s before all the memes 😥). Not to worry, it was cut down, but still you should expect a monstrum of edition.

Sooo… without further ado - let’s start!

1. Language and Platform

We’ll start our “small” overview with JVM languages and all the changes happening within the JVM itself. I’ve selected only the most important new developments… although even those are plentiful. The order is random (more along the lines of “whatever came to mind first,” so there’s a certain chaotic prioritization to it). Enjoy!

Java turns 30!

Let’s start with the birthday wishes: Java this year turned 30 and has entered its fourth decade with style, under Oracle’s banner. Already back in March, JavaOne 2025 adopted an anniversary theme, adding retrospective keynotes and a special “Java at 30” track. The Inside Java newsletter also covered the behind-the-scenes details and celebration plans in its May issue, encouraging the community to join in. On top of that, May 22nd saw a six-hour livestream featuring James Gosling , Brian Goetz , Mark Reinhold , and Georges Saab , hosted by Ana-Maria Mihalceanu , Billy Korando , and Nicolai Parlog.

Partners and vendors joined the toast: JetBrains launched the #Java30 campaign with a What’s your inner Duke? quiz and limited-edition T-shirts up for grabs.

JetBrains also published a “Java Good Reads” list, released a plugin that changes the IDE splash screen, and even dropped a “Java 30” TikTok duet track. And before anyone tries to be cool asking, “What even is TikTok?”, just go play that song.

But that’s not all! Here are a few more highlights:

• Azul hosted its virtual event, Duke Turns 30, as early as March, gathering Java Champions for panels on the future of JVM performance.

• Also in March (because who says you have to celebrate only on your actual birthday?), Payara looked back at Java’s journey, highlighting the evolution from set-top boxes to microservices in the cloud.

• The community joined in too: Cyprus JUG hosted an evening of lightning talks and a Duke cake on May 23rd, and similar events popped up in the calendars of many JUGs and conferences, adding special anniversary sessions.

The upshot of all these distributed but coordinated initiatives is more than just a nostalgic tribute: joint events, open-access content, and new IDE plugins are strengthening the network of relationships that has kept the Java ecosystem vibrant for 30 years - and is preparing it for another decade of innovation.

And hey, in just ten years we’ll be celebrating Java’s 40th. Because, let’s face it, Java is forever.

Virtual Threads finally without Pinning

For nearly two years since their debut in JDK 21 (yes, JDK 21 was published 2 years ago), the results of Project Loom had one major “but” that effectively cooled enthusiasm in large codebases: pinning virtual threads on synchronized monitors. In theory, virtual threads were meant to be a lightweight and massively scalable at the same time, but in practice every synchronized block could pin them to a platform thread - destroying scalability where Java has the most legacy code… so in places where failures tend to surface at the least expected moment. Yes, the documentation warned about it, conference talks advised migrating to ReentrantLock, but in reality teams looked at millions of lines of existing Java and postponed Loom “until later.” I personally had that discussion more than once.

JDK 24 closes this chapter. Thanks to changes in the JVM monitor implementation (JEP 491), virtual threads are no longer automatically pinned when entering a synchronized block. As long as they do not perform operations that genuinely require binding to an OS thread, synchronized blocks can be unmounted and remounted just like any other virtual thread.

The importance of this change is hard to overstate, because - contrary to what might seem to a generation raised on java.util.concurrent, those summer children - synchronized is not an exotic detail but a core Java idiom that has been present from the very beginning in standard libraries, frameworks, application servers, and business code that has been running in production for decades… and will likely remain there for decades to come (Lindy effect, anyone?). Previously, Loom required teams to undertake conscious, often costly refactoring to avoid pinning. Now virtual threads become compatible with idiomatic Java of the past, so migration stops being an architectural project and becomes a purely runtime decision.

It is the moment when the narrative around Loom can finally change. Until JDK 24, it was irresponsible to approach the topic in any way other than “virtual threads are great, but…”, and as we all know, the “but” negates everything that comes before it.

Visualization:

Stream Gatherers finally open up the Stream API

From the very beginning, the Stream API contained a certain contradiction. On the one hand, it offered an elegant, functional way to describe data processing - it is probably the widest used “new” Java feature. However, it was surprisingly closed to extension, which clashes strongly with what one would expect from this kind of functionality… especially people coming from more functional background were rolling eyes. For years, JVM developers kept coming back to the same problem: as long as map, filter, and reduce are enough, everything is fine. But as soon as you need windowing, stateful scanning, rolling aggregates, or more complex transformations, all that elegance disappears into the depths of collect() and custom, hard-to-read Collectors.

JEP 485 and Stream Gatherers are a direct response to this long-standing tension. Instead of stuffing all the logic into a terminal collector, you can now define your own intermediate operations that behave like native elements of the pipeline. windowFixed, scan, fold, and other stream-processing patterns stop being hacks and, crucially, they preserve lazy evaluation and compose naturally with the rest of the stream. In practice, this means less imperative code, fewer external libraries, and much better readability in places where streams previously lost out to classic loops (which are surprisingly flexible pattern in the end).

Also, it’s good to see Java is increasingly choosing the path of “opening up existing abstractions” rather than creating entirely new APIs from scratch.

Class-File API and the end of the “ASM Dependency Era”

If Stream Gatherers change the day-to-day style of writing code - and I suspect most of you will use them at some point, even indirectly through a third-party library - then Class-File API (JEP 484), while remaining largely invisible, changes the very foundations on which the JVM ecosystem has stood for years. For two decades, bytecode manipulation was in practice synonymous with a single library: ASM. Every framework that generated or modified classes - Spring, Hibernate, Mockito, Byte Buddy, testing tools, profilers - had to rely on an external project that was constantly racing ahead of Java’s evolution. Even Java itself used it internally.

This was a quiet but very real structural problem. Every new JDK release meant a race: does ASM already support the new classfile format? Have the frameworks caught up? Will a preview feature break builds? The ecosystem lived in a state of permanent synchronization with a library that was formally “external” but, in practice, absolutely critical.

JEP 484 puts an end to this arrangement. Manipulating .class files becomes part of the JDK, with an official API and compatibility guarantees for future versions of the format. Responsibility for the evolution of the classfile returns to where it always should have been: the platform itself. Frameworks no longer have to guess how to read a new version of bytecode and can instead rely on a contract provided directly by Java.

Even though most of you will never touch classfiles directly, this is a change with enormous significance for the long-term maintainability of the platform. Fewer dependencies, fewer risky upgrades, less “waiting for someone to release a new version of ASM.” But it’s also something more: the internalization of critical infrastructure as certain parts of the ecosystem are too fundamental to live outside the standard library.

Class-File API won’t suddenly make the average developer start writing bytecode-level code (thanks God). But for framework authors, tool builders, and platform engineers, it’s one of the most important JEPs in years - one that reduces friction across the entire ecosystem.

Java enters the Post-Quantum Era before it becomes necessary

Post-quantum cryptography is a topic that’s easy to dismiss with a shrug: “quantum computers aren’t breaking RSA yet, so we still have time.” JEP 496 and JEP 497 introduce the first native implementations of the ML-KEM and ML-DSA algorithms into Java—used for key exchange and digital signatures respectively - aligned with the newly finalized NIST FIPS 203 and 204 standards.

Behind this lies the very pragmatic “harvest now, decrypt later” concept. Data encrypted today with classical asymmetric algorithms can be intercepted and decrypted in the future, once quantum hardware matures. For sectors such as public administration, banking, defense, healthcare, or data archives, the implication is straightforward: if information needs to remain confidential for 20–30 years, migration has to start now - not on the day the first “breakthrough” quantum computer appear

Compact Object Headers Graduate from Experimental Status

This is one of those JVM changes that doesn’t alter a single line of code, yet can completely change the economics of an application. JEP 519 moves Compact Object Headers from the experimental phase into full production, closing out years of work on slimming down one of the most fundamental structures in Java: the object header.

For decades, the object header in HotSpot was relatively “fat” - 96 or even 128 bits, depending on configuration and architecture. It carried everything: synchronization data, GC information, the class pointer, the hash code. JEP 519 reduces this overhead to 64 bits without sacrificing functionality. The result? In applications with a large number of small objects - which in practice means almost every modern JVM service - heap usage drops by an average of ~22%. And that’s no small thing. In the world of microservices, containers, and cloud-native deployments, memory is one of the primary operational costs. A smaller heap also means smaller pods, smaller VMs, faster cold starts, shorter GC pauses, and very real reductions in infrastructure bills.

Compact Headers have been tested, measured, and benchmarked extensively on real workloads. Promoting them to stable version means that OpenJDK considers them safe not only from a performance perspective, but also expects no surprises in synchronization, hash codes, or interactions with the garbage collector.

Pinky swear.

Scoped Values — the Quiet Successor to ThreadLocal

Scoped Values are one of those Project Loom features that don’t make much noise (at least not as much as Stream Gatherers), yet they significantly change how safe, concurrent code is written in Java.

The problem Scoped Values address is old and well known: ThreadLocal. For years, it was the only reasonable way to propagate context - request IDs, security context, transactions, locale - without threading it through every method parameter. But ThreadLocal has two fundamental flaws. First, it lives as long as the thread does, which in a world of thread pools led to leaks, subtle bugs, and “bleeding” context. Second, it doesn’t fit virtual threads, where a thread stops being a long-lived carrier of context and becomes a lightweight, ephemeral abstraction.

Scoped Values invert this model. Instead of binding data to a thread, they bind it to an execution scope. A value is visible only within a clearly defined block, automatically propagates down the call stack, and—crucially—disappears exactly when the scope ends. No cleanup, no leak risk, no magical hooks. Another advantage of Scoped Values is that they are easier for the JVM to optimize. Their immutable nature and bounded lifetime mean the runtime knows precisely when a value exists and when it is no longer needed.

In short: if ThreadLocal was a hack that allowed Java to survive the era of application servers, Scoped Values are the mechanism that lets it enter the Loom era without repeating the same mistakes.

But remember - there is nothing wrong in a good hack. Even Gods-and-Saviours are doing that from time to time

JFR enters everyday observability

Java Flight Recorder has long been one of the most underrated components of the JVM. Powerful and low-overhead, yet often treated like a “black box” that you only look into after something goes wrong. JDK 25 clearly changes this role. The expansion of JFR in 2025 shows that Oracle increasingly sees it as a continuous source of data about application behavior, not just a post-mortem tool.

A key step here is JEP 509, which introduces CPU-time profiling on Linux. Until now, most profiles were based on wall-clock sampling, which in shared environments—containers, cgroups, noisy neighbors—often led to misleading conclusions. CPU-time profiling answers a much more practical question: where does the processor actually spend its time? This is especially important in the cloud, where every millisecond of CPU has a real cost at scale, and the difference between “waiting” and “computing” is crucial for optimization.

The second element, JEP 520, moves JFR toward analyses that previously required external tools or costly instrumentation. Method Timing & Tracing with bytecode instrumentation makes it possible to measure method execution time with much greater precision, without manually attaching profilers or agents (the JVM ones—for AI agents, we’ll get to that later). For the first time, JFR starts looking inside application code, not just observing it from the runtime level.

All of this is tied together by cooperative sampling - a mechanism that improves measurement accuracy while maintaining very low overhead. Instead of aggressively interrupting threads, the JVM cooperates with the executing code, resulting in more stable and representative data. In practice, this means JFR can run continuously in production without fear of a noticeable performance impact. Java Flight Recorder therefore stops being a Plan B for when the world is already on fire, and starts becoming the default way of understanding a JVM application in motion.

From backstage: this is the moment Substack informed I’m approaching the email limit - What can I say, are you f*cking kiddin’ me? I’m just getting up to speed.

Project Valhalla - After a decade, Java finally touches the metal

Project Valhalla is probably the most patiently developed project in the history of OpenJDK. When Brian Goetz announced it back in 2014, the Java world looked very different: there was no Loom, GraalVM was still an academic experiment, and “cloud-native” hadn’t yet become an overused buzzword. For many years, Valhalla existed more as an idea than a roadmap—names changed (inline types, value types, primitive classes), and assumptions were alternately tightened and relaxed.

In 2025, that changed. JEP 401: Value Classes and Objects reached Candidate status, and Oracle released the first early-access builds. This is the first moment when Valhalla stopped being just a Brian Goetz slide deck and became a concrete proposal for changes to the language and the VM.

What’s most striking is how little changes on the surface. One new keyword - value - placed before class or record… and that’s basically it. But beneath this modest syntax lies a fundamental shift in Java’s object model. Value classes give up object identity. Two objects with the same field values are indistinguishable - == ceases to be a reference comparison and becomes a value comparison. It’s a radical but consistent decision: if something has no identity, the JVM no longer has to pretend that every instance “lives its own life” on the heap.

Brian Goetz has summed up Valhalla in a single sentence for years: “code like a class, work like an int.” The core promise of Valhalla is flattening—the ability to place value object data inline in memory, without an extra layer of indirection. An ArrayList<Point> where Point is a value class is no longer an array of pointers to objects scattered across the heap, but a compact array of coordinates. Fewer dereferences, fewer cache misses, better data locality. This is exactly the kind of optimization that’s obvious in C or C++, but was historically out of reach in Java.

Why does this matter so much right now? Goetz often points out that the JVM memory model dates back to the early 1990s. In that world, the cost of memory access and the cost of arithmetic were comparable. In 2025, the difference is on the order of 200–1000×. Java, with its pointer-centric object model, pays a real price for this—especially in numerical code, game engines, stream processing, ML, and HPC. Valhalla is an attempt to regain control over memory layout without abandoning the safety and abstractions that made Java popular in the first place.

Importantly, Valhalla’s design in 2025 is far more pragmatic than in its early iterations. Earlier proposals assumed almost “sterile” isolation of value types. JEP 401 - still not yet targeted to a specific JDK release - allows abstract value classes and softens the boundaries between the reference world and the value world. This signals that the project aims not for academic purity, but for real-world adoptability, including in existing codebases.

At the same time, after years of “not yet,” we finally have a concrete JEP, concrete early-access builds, and a very clear trajectory. Java is beginning to repay its debt to the hardware it actually runs on - and has a chance to change the deepest foundation of all: the relationship between objects and memory.

Congratulation Valhalla team! However I have one thing in my mind

Project Panama and Project Babylon - Java steps beyond its own walled garden

If Loom changed the way Java thinks about concurrency, and Valhalla about memory, then Panama and Babylon go one step further and evolve how the JVM cooperates with the world beyond itself. For decades, Java has been a safe, portable, and… hermetic platform. Integration with native code existed, but JNI was a tool from the “use only as a last resort” category. GPUs, SIMD, specialized hardware? That usually meant C++ wrappers with a thin layer of Java on top. Panama and Babylon are an attempt to break away from this model - without abandoning the JVM.

Project Panama, whose culmination was the introduction of the stable Foreign Function & Memory API, tackles the most down-to-earth and painful problem: how to talk to native code safely and efficiently.

But that’s only half the story. Panama solves how to get outside JVM, but not why Java kept losing in areas such as HPC, GPUs, or intensive numerical computation. And that’s where Project Babylon comes in.

Babylon is one of the most ambitious projects in OpenJDK - and at the same time one of the least understood. Its goal is not to “speed up Java,” but to make Java a language capable of mapping itself onto modern hardware. In practice, this means enabling Java code - when properly described - to be compiled to different backends: CPUs with SIMD, GPUs, and AI accelerators. Not through magical runtimes, but through an explicit, analyzable computation model.

The key here is its connection to Valhalla and Panama. Valhalla’s value classes make it possible to describe data structures, while Panama provides safe access to memory and native ABIs. Babylon ties this all together by delivering a model in which the JVM can understand the semantics of computations, not just execute them on a CPU. Projects like TornadoVM already show today (which we’ll get to shortly) that Java can be a viable language for GPU programming - Babylon is meant to ensure this stops being a curiosity and becomes a feature available to the “common programmer.”

And that’s important - as Java is no longer just a language for backends and microservices. It is starting to become an infrastructural language that can handle everything: from classic services, through AI inference, to heterogeneous computing. And importantly - without copying the C++ or CUDA model. While preserving type safety, garbage collection, and the tooling that have been its advantages for years.

For now, Babylon is still a research project, but by the end of 2025 it remains one of the missing pieces of a puzzle that has been taking shape in OpenJDK for over a decade. If you want to learn more - this is the best material you can find nowadays.

Project Leyden: AOT as an Answer to GraalVM Native Image

For years, the discussion around JVM application startup time has been dominated by a single solution: GraalVM Native Image. Radically effective and impressive in benchmarks, but paid for with real costs - long compilation times, a “closed world,” and constant battles with reflection and libraries that assume JVM’s dynamic nature. Project Leyden was created as a conscious alternative to that philosophy. Not as yet another AOT mode, but as an attempt to achieve similar benefits without giving up what has defined Java for decades.

The key assumption behind Leyden is that most server applications are not chaotic. On the contrary - they are surprisingly predictable, boring even. The same classes are loaded on every startup. The same code paths warm up at the beginning. The same proxies, the same reflection metadata, the same execution profiles. JVM has long been able to see these patterns, but until now it discarded this knowledge on every restart - Leyden changes exactly that.

Leyden’s philosophy is speculative runtime optimization. The JVM observes the application during a so-called training run and assumes that future runs will be similar. Execution profiles are not random; they are a stable artifact of the application: classes that were needed will be needed again, and methods that were hot are worth preparing in advance. Instead of starting “from scratch” on every launch, the JVM begins to learn its own behavior.

In 2025, Leyden began to materialize in the mainline JDK. The foundation consists of three JEPs that together define a new JVM startup model. JEP 483, introduced in JDK 24, enables Ahead-of-Time Class Loading & Linking - the most expensive part of JVM startup can be done in advance and stored in a cache. JEP 514 simplifies the launch ergonomics, reducing the entire workflow to a single, sensible command instead of a set of experimental flags. JEP 515 allows method execution profiles to be preserved across runs, opening the door to much more aggressive optimizations without sacrificing safety.

In August 2025, Leyden Early Access 2 appeared, showing where the project is actually heading. For the first time, we saw the outline of AOT code compilation - methods can be compiled to native code during the training run and stored in a cache, so the work doesn’t have to be repeated on the next startup. On top of that comes AOT for dynamic proxies and reflection data - two areas that historically caused the biggest problems for both the classic JVM and Native Image. Crucially, all of this still works within HotSpot, without closing the world and without breaking the contract of dynamic behavior.

Leyden is not trying to beat GraalVM Native Image on its own turf. Instead, it redefines the reference point. If Native Image is an extreme - minimal startup at the cost of flexibility - then Leyden pushes the classic JVM as far toward “fast startup” as possible without abandoning dynamism. For the vast majority of enterprise applications, this is exactly the compromise that was missing. Project Leyden is, in practice, OpenJDK’s answer to the question: can the JVM be fast at startup without ceasing to be a JVM? In 2025, for the first time, the answer began to sound like: yes.

And since we’ve already invoked GraalVM…

GraalVM in 2025 - From “Java’s Savior” to a specialized runtime (with AI Inside)

Well… 2025 was one of the most turbulent years in GraalVM’s history. Not technologically - because on that front GraalVM made enormous progress - but strategically. Oracle very clearly shifted its priorities, effectively closing a certain era in thinking about GraalVM as “the future of Java.”

The most important signal came early: GraalVM for JDK 24 is the last release licensed as part of Java SE. The experimental Graal JIT, which in Oracle JDK 23 and 24 could replace C2 as an alternative compiler, has been withdrawn. Native Image is no longer part of the Java SE offering, and Oracle is explicitly steering customers toward Project Leyden as the default path for JVM startup and runtime optimization. For many observers, this was a “wake-up moment”: GraalVM is not disappearing, but it is no longer the universal answer to all of Java’s problems that it seemed to be over the past decade.

At the same time - and here lies the most interesting paradox - GraalVM has never been technologically stronger than it was in 2025. Instead of focusing on being a “better HotSpot,” the project fully embraced its unique identity: extremely aggressive AOT, a compiler as a research platform, and a proving ground for techniques that the classic JVM cannot adopt as quickly.

The best example of this shift is GraalNN - a neural-network-based static profiler. It is one of the most underrated yet most radical ideas in the compiler world in recent years, and it fits perfectly into the zeitgeist of 2025. Instead of relying solely on runtime profiles or simple heuristics, GraalVM uses a trained neural network that predicts branch probabilities based on the structure of the control flow graph - the compiler starts guessing how the code will behave before it ever runs. This is an evolution of the earlier GraalSP based on XGBoost, which has been enabled by default since version 23.0 - but GraalNN goes further. On top of that comes SkipFlow, an experimental optimization that tracks primitive values across the entire program and evaluates conditions already at the static analysis stage. In the world of Native Image, where every kilobyte and every method matters, this is a very concrete advantage.

In parallel, a new and interesting thread emerged: GraalVM and AI at the application level. Quarkus began exploring streamable HTTP and MCP in the context of LLMs, based on its fork of the project - Mandrel - while Oracle is positioning GraalPy as a runtime for building AI agents and workflows (e.g., LangGraph) with very low overhead and good integration with JVM-based backends.

At the same time, support for macOS x64 was dropped without sentimentality - GraalVM 25.0.1 is the last release for Intel; the future is exclusively Apple Silicon.

And this brings us to the key conclusion the community reached in 2025. GraalVM is no longer seen as a competitor to HotSpot and Leyden (rather, Leyden stopped being “GraalVM for the masses,” gradually pushing its older sibling out of its natural habitat). Instead, it has found its place as a specialized runtime and compiler: ideal where extreme trade-offs matter - serverless, CLI tools, edge computing, AI inference, native integration, minimal binaries. As Leyden takes over the mainstream JVM, GraalVM occupies the extreme end of the spectrum.

This was a difficult but healthy narrative correction. For years, GraalVM was the answer to criticisms from the Rust or Go communities, proudly pointing out that Java also had its own native format - though one that never broke into production to the extent the surrounding community had hoped. Now that it no longer has to “save Java,” it can focus on what it does best: experimenting faster than the mainline, bringing ML into compilation, and pushing the boundaries of AOT. And Java - paradoxically - comes out better for it, because instead of one tool for everything, it gains a coherent spectrum of solutions.

I think it’s fair to say that in 2025 it became clear: GraalVM is not the future of the entire JVM. But without GraalVM, that future would look significantly poorer.

Jakarta EE - The Year that breathed life into a “Dead” Platform

If anyone had written Jakarta EE off a year ago, 2025 must have felt like a cold shower. This was the year the platform stopped merely catching up and actually started building its future.

Jakarta EE 11 - after 34 months since the previous release - finally saw the light of day. First came the Core Profile (December 2024), then the Web Profile (March 2025), and the full platform on June 26. The delay, however, made sense: the Working Group spent that time thoroughly modernizing the TCK - migrating from Ant/TestHarness to Maven/JUnit 5/Arquillian. Boring? Yes. But it was precisely this “plumbing” that had blocked progress for years and scared off new vendors.

Version 11 itself brings two stars: Jakarta Data 1.0 - an answer to Spring Data without Spring, with repositories defined via interfaces and implementations generated automatically—and Jakarta Concurrency 3.1 with full support for Virtual Threads. On top of that come Java Records in Persistence and Validation, the removal of the Security Manager, and the deprecation of Managed Beans. The platform is finally speaking the language of modern Java.

And that’s not all. In March, Jakarta NoSQL 1.0 was approved - a specification standardizing access to document, graph, and key-value databases with an API modeled after JPA. It didn’t make it into EE 11, but it paves the way for future profiles.

And in the fall? Jakarta Agentic AI - a project under the Eclipse Foundation umbrella (initiated by Payara and Reza Rahman) that aims to define a vendor-neutral API for AI agents: lifecycle, integration with CDI and REST, and standard guardrails. The first release is planned for Q1 2026. At the same time, MicroProfile AI is taking its own, more pragmatic path - trying to integrate LangChain4j into the ecosystem without waiting for full specifications.

Greetings to the rest of technical community from the more peaceful wotld.

However, for those who crave emotions and enjoy the behind-the-scenes drama - over the summer, a governance conflict played out on the mailing lists. For years there have been discussions about merging MicroProfile into Jakarta EE (a logical step, since MicroProfile already depends on the Core Profile), but such a merge requires a so-called super-majority. David Blevins (Tomitribe) publicly announced that a coalition of several vendors has enough votes to block it—not because they oppose integration per se, but pending resolution of a conflict of interest. The crux of the dispute: within the Jakarta EE Working Group structure sits EE4J—a parent project that includes GlassFish. Blevins argues that the WG’s budget, marketing, and community programs effectively promote one implementation at the expense of competitors (Payara, Open Liberty, WildFly, TomEE). His proposal: split EE4J into a separate structure, and let the Jakarta EE WG focus solely on specifications. OmniFish (the GlassFish steward) agrees to the split but denies any intentional favoritism—calling it historical baggage that is gradually being removed. Current status: in November, a proposal passed to retain the org.eclipse.microprofile.* namespace in the event of a merge—a signal that the community is preparing for integration without repeating the pain of javax.* → jakarta.*. but the EE4J issue remains unresolved.

Additionally: the plan for Jakarta EE 12 (scheduled for July 2026) has already been approved - mandatory JDK 21, support for JDK 25, new specifications Jakarta Config and Jakarta Query, deprecation of the Application Client, and further consolidation of the data layer.

Not a bad year for a “dead” platform.

Scala Says Goodbye to JDK 8

For a decade, JDK 8 was the anchor of the JVM ecosystem - but that era is coming to an end. Spring Boot 3 requires JDK 17. Jakarta EE 10 has a minimum of JDK 11. Hibernate 6, Quarkus 3.7, Micronaut 4 - all have gone down the same path. And it is precisely in this context that Scala made its most symbolic move in 2025. In March, the Scala team officially announced its decision: JDK 17 will become the new minimum, starting with Scala 3.8 (currently in RC4, so the release is likely imminent) and the next LTS (most likely Scala 3.9). Not JDK 11 - straight to 17. The discussion about whether to also drop JDK 11 revealed no convincing reason to keep it—11 is now almost as outdated as 8.

The direct reason? The implementation of lazy val in Scala - one of the language’s most distinctive constructs - relies on low-level operations from sun.misc.Unsafe, which are necessary to ensure correct behavior in multithreaded environments (initialization must happen exactly once, even when multiple threads access the value simultaneously). The problem is that Oracle has been planning to remove these methods for years - JEP 471 officially deprecates them, and future JDKs (25+) may remove them entirely. Scala therefore had to rewrite the lazy val implementation using a newer API (VarHandle), which is only available starting with JDK 9. Maintaining two code paths - the old one for JDK 8 and the new one for newer versions - was deemed too costly.

There is also a beautiful irony in all of this: for years, Scala was ahead of Java (pattern matching, sealed types, ADTs). Java eventually caught up with Scala at the language level - and now Scala can finally take advantage of the bytecode that Java created… inspired by Scala. The loop is complete.

Kotlin and the Moment When K2 Stops Being “New”

After Kotlin’s very dynamic development in 2024, with the highlight being version 2.0 in May, 2025 became a year of normalization. Kotlin 2.2 (June) and 2.3 (December) no longer try to convince anyone that K2 is the future - they assume instead that “the future is now,” and focus on what ultimately determines real adoption: performance, ergonomics, and ecosystem completeness.

The most telling signal is therefore tooling-related rather than language-level. K2 mode became the default in IntelliJ IDEA (from 2025.1). This means that code analysis, completion, highlighting, and refactorings in the IDE are powered by exactly the same engine that compiles the code. JetBrains decided that K2 is stable and fast enough to become the foundation of the entire workflow.

Kotlin 2.2 and 2.3 (which we didn’t covered yet in JVM Weekly, but it time will come) represent a maturation phase - rather than a single “killer feature,” we get a series of small but noticeable improvements. Guard conditions in when, context parameters that organize dependencies, non-local break/continue, multi-dollar string interpolation—these are changes that don’t make a splash (you’ve probably already forgotten what was in the previous sentence), but save time every day. API stabilization (HexFormat, Base64, UUID), compatibility with Gradle 9.0, new mechanisms for source registration - Kotlin stops living “alongside” the JVM toolchain and starts being co-designed with it.

At the same time, Kotlin Multiplatform continues to mature - a technology that for years was both the biggest promise and the biggest question mark. Compose Multiplatform for iOS reaches production-ready status in 2025, and not in the sense of “it works in a demo,” but as a fully-fledged UI stack: native scrolling, text selection, drag-and-drop, variable fonts, natural gestures. Add to that Compose Hot Reload, which dramatically shortens the feedback loop. This is the moment when UI stops being the “weak link” of KMP.

In the same context, Swift Export appears - still in preview, but highly symbolic. Kotlin no longer integrates with Swift via Objective-C, and instead starts exporting APIs directly into the Swift world.

The tooling backend is also being cleaned up. kapt uses K2 by default, old flags are being deprecated, and annotation processing finally stops being a “parallel world” alongside the new compiler. Alongside this, Amper continues to evolve—still experimental, but increasingly positioned as an alternative where Gradle is too heavy and tight IDE integration matters more than maximum configurability.

There is, of course, Kotlin LSP - but it is such an interesting phenomenon in its own right that we’ll come back to it later.

Clojure Is… AI-Skeptical

In 2025, Clojure did something that, in the age of “AI everywhere,” feels almost countercultural: instead of trying to win the fireworks race, it focused on steadily closing the gaps in the language’s and tooling’s foundations. The most “official” rhythm of the year came from successive releases in the 1.12.x line. On paper, these were tiny releases, but they’re quintessentially Clojure: semantic fixes, compiler improvements, visibility and safety issues in LazySeq and STM - the kinds of changes that improve the predictability of systems meant to last for years.

And here’s the most interesting part: this “quiet” year for the language itself collided with a very loud statement from Rich Hickey about AI - a statement that, in many ways, explains why Clojure in 2025 looks the way it does. In early January 2026, Hickey published an essay titled “Thanks AI!” (sneaking into this overview at the last possible moment), in which he directly addresses the side effects of generative AI: from flooding the world with “slop,” through degrading search and education, to cutting off the entry path for juniors (the disappearance of entry-level jobs as a “road to experience”). Classic Hickey: evaluating technology through the lens of whether it reduces complexity and improves the quality of social systems, not just technical ones.

Instead of building “the Clojure AI agent framework of the year,” the community pumped energy into tooling and ergonomics. Clojurists Together’s 2025 reports explicitly show where funding and effort went: to people working on clojure-lsp and IDE integration, on clj-kondo, babashka, and SCI, on CIDER - in other words, on things that shorten the feedback loop and improve the quality of everyday work, regardless of whether an LLM is involved in the background.

And this is, paradoxically, one of the most important things about Clojure in 2025: in a world where many ecosystems respond to AI with a marketing reflex, Clojure responds… like Clojure. Quality, semantics, and tools first. The rest can wait.

Groovy 5.0 - A New (Small) Impulse for a Classic JVM Language

Groovy has a long history behind it - from a dynamic, “magical” JVM language that in the mid-2000s was one of the most interesting alternatives to Java, inspired by Ruby (the ultimate “cool kid” language of its time), through a scripting platform used in Gradle, Jenkins, and Grails, to today’s ecosystem where its mainstream adoption has been declining in favor of Kotlin/Java and more strongly typed tools.

Released in the summer of 2025, Groovy 5.0 is the first major revision since Groovy 4 and an attempt to bring more modern language features and tooling quality into a project that for a long time was seen more as a “support tool” than a fully fledged programming language. The release includes a wide range of improvements: broad compatibility with JDK 11–25, hundreds of new or enhanced extension methods for Java’s standard APIs, a reworked REPL console, better interoperability with modern JDK versions, and a number of conveniences for working with collections and iteration. All of this is meant to ensure that Groovy doesn’t fall behind in the era of newer JVM platforms.

One of the most anticipated features of 5.0 is GINQ (Groovy INtegrated Query) - a SQL-style query language built into Groovy that allows collection and data-structure operations to be expressed in a more declarative way. This functionality already existed in earlier 4.x versions, but in 5.0 it is strengthened and treated as a first-class part of the language. GINQ offers capabilities similar to LINQ in .NET, with from, where, orderby, and select clauses, and support for working with different kinds of data sources.

The community’s reception of Groovy 5.0 has been mixed, which is hardly surprising given the language’s position in 2025. Developers still invested in Groovy appreciate the modern improvements - such as better performance for collection operations, fixes to the REPL and interoperability, and the fact that the project continues to evolve beyond 4.x. As some commentators put it, this is “the best version of Groovy so far,” with hundreds of fixes and extensions. On the other hand, discussions and forum posts also point out that the language continues to struggle with limited adoption and tooling support outside its traditional niches, such as CI/CD scripts, Gradle DSLs, or automation tasks.

All in all, Groovy 5.0 is an interesting release: it delivers new language features, stronger JDK compatibility, and improved ergonomics, while at the same time fighting for attention in a JVM landscape dominated by Kotlin, Java, and statically typed tools. Its role in projects like Gradle (where it is gradually being displaced by Kotlin), Grails (which itself is no longer a popularity powerhouse), or Jenkins shows that the language still has its place - but its development in 2025 is more evolutionary than revolutionary.

2. What’s Happening in the Community

OpenRewrite: From a Tool to an Ecosystem

Not long ago, OpenRewrite existed in the collective consciousness as “that tool for migrating Spring Boot.” Useful and effective, but still fairly narrowly pigeonholed. In 2025, that phase definitively ended. OpenRewrite stopped being a product and started functioning like infrastructure - quiet, embedded, often invisible, but absolutely critical to how code in the JVM ecosystem is modernized today.

A symbolic moment was OpenRewrite being built directly into IntelliJ IDEA starting with version 2024.1. From that point on, it was no longer a plugin for enthusiasts, but a first-contact tool. YAML recipes with autocompletion, inline execution of complex transformations, gutter-based migration runs, and debugging scans and Refaster rules turned automated refactoring from a “special operation” into a normal part of everyday IDE work. When JetBrains treats a tool as part of the editor itself, it usually signals that the ecosystem has matured to a new standard.

In parallel, Microsoft’s App Modernization initiatives built around GitHub Copilot do not “write migrations” themselves. Copilot plans steps, explains changes, and closes error loops—but the deterministic code transformation is performed by OpenRewrite itself. AI analyzes the codebase and proposes a migration sequence, OpenRewrite applies semantic transformations, and Copilot iteratively fixes compilation and test failures. Java 8 → 25, Spring Boot 2 → 4, javax → jakarta, JUnit 4 → 6—without a semantic refactoring layer, this entire process would degrade into little more than prompt engineering and hope. Even the most advanced LLM-based tools still require a deterministic refactoring engine underneath to constrain stochastic behavior.

The same pattern appears elsewhere. Azul integrates OpenRewrite via Moderne rather than building its own refactoring system, combining automated code transformations with runtime insights from Azul Intelligence Cloud.

What’s most interesting is how many tools now rely on OpenRewrite without exposing that dependency prominently. Moderne is the obvious example, but the same pattern can be observed in security auditing tools, compliance platforms, mass repository migration systems, and internal “code remediation” platforms built by large organizations. OpenRewrite is increasingly playing the same role for refactoring that LLVM plays for compilers - a shared substrate on which others can build workflows, UIs, and integrations without reimplementing parsers, visitors, or semantic analysis from scratch.

At the same time, the technical scope of OpenRewrite continues to expand beyond Java. It now supports JavaScript, TypeScript, Android, and increasingly complete Scala coverage, with rapid parser updates tracking Java 25, Spring Boot 3.5, and Spring Cloud 2025. The OpenRewrite recipe catalog has surpassed 3,000 entries, evolving from a simple list of migrations into a living knowledge base that captures how large, long-lived systems actually evolve in practice.

Have fun with JavaScript, OpenRewrite.

Private Equity Enters the Game: Azul Acquires Payara

On December 10, 2025, Azul announced the acquisition of Payara—the company behind the enterprise fork of GlassFish and one of the last truly serious players in the Jakarta EE world. On paper, this looks like a classic product acquisition. In practice, it’s a much deeper move that closes a long sequence of events.

Just a few weeks earlier, Thoma Bravo entered Azul. And when private equity of that scale shows up in a technology company, it’s usually not about maintaining the status quo - it’s about building a platform capable of aggressive growth.

For years, Azul has been a very clearly profiled company: an excellent JDK, extremely strong expertise in performance, stability, and security—but still just one fragment of the overall stack. For large Java customers (you know - the true enterprise+ scale), the story rarely ends at the JVM. It ends with the question: “what about the application server themselves?”

And this is exactly where Payara comes into the picture.

For years, Payara has existed somewhat outside the main hype cycle, consistently serving organizations that could not - or did not want to - abandon Jakarta EE. Banks, public administration, industry - places where applications live for decades, not quarters.

For Azul, this was the missing piece of the puzzle. The acquisition of Payara makes it possible to offer customers a complete, coherent story: from the JDK, through the runtime, all the way to the application platform. One responsibility, one vendor, one operating model. The broader market context is even more interesting. The application server market - declared dead many times over, even in this article itself - is today worth tens of billions of dollars (yes, I was surprised too).

Why? Because microservices and the cloud didn’t erase monoliths - they merely added new layers alongside them. Organizations are migrating, but they do so in stages. And they need platforms that can handle both the “old” and the “new” at the same time.

BM Merges the Red Hat Java Team… and Buys Kafka

Azul isn’t the only company trying to give customers a more focused, end-to-end offering. 2025 brought two IBM moves that, taken separately, look like routine corporate reshuffles—but together form something much more interesting: an attempt to build a coherent enterprise stack that actually lives in real time, instead of pretending to analyze data “almost instantly.”

Early in the year - fairly quietly (unless you read JVM Weekly, in which case not quietly at all) - Red Hat’s Java and middleware teams were merged into IBM’s Data Security, IAM & Runtimes organization. Sounds like just another reorg? Maybe. But the context matters.

Since IBM acquired Red Hat in 2019 for $34 billion, the two companies have effectively been running parallel JVM universes: Red Hat with JBoss EAP, WildFly, and Quarkus and IBM with WebSphere, Open Liberty, and OpenJ9.

Two teams, two roadmaps, two philosophies tackling the same problem. Now they’re meant to be one. The projects remain open source (WildFly and Quarkus were moved under the Commonhaus Foundation), but middleware strategy is now owned by a single organization - not two competing ones.

December, however, brought the real fireworks: IBM buys Confluent for $11 billion in cash. Eleven. Not “considering,” not “exploring” - done, signed, with a premium and full commitment. And suddenly, everything clicks.

Kafka may be the backbone of real-time data, but Confluent has never been profitable - billions in losses over the years - which made many analysts skeptical. IBM sees it differently: 45% of the Fortune 500 already use Confluent products. For a startup (okay, not that small anymore), that’s success. For Big Blue, it’s a list of customers who don’t yet realize they need event-driven architecture bundled with 24/7 support and long-term enterprise contracts.

And this is where Java comes back into the picture. Red Hat gave IBM the platform (OpenShift). HashiCorp (deal finalized this year as well) delivered infrastructure as code. Confluent brings real time.

The newly unified Java/middleware team is supposed to glue all of this into a single, predictable stack for enterprises that want to build event-reactive systems.

It’s an interesting bet: IBM is wagering that the future of enterprise isn’t better dashboards, but architectures where data stops being “what happened” and becomes “what is happening.” And to do that properly, you need runtimes (the Java stack), a platform (OpenShift), orchestration (Terraform), and a circulatory system (Kafka).

Will it work? Time will tell. But one thing is certain: IBM didn’t buy Confluent to improve the next quarterly report. The effects should become visible pretty soon.

Cause always remember the crucial difference:

Canonical Releases Its Own JDK

And while we’re on the topic of JDK teams tied to Linux distributions…

July also brought something unexpected: Canonical announced its own Canonical builds of OpenJDK - binary OpenJDK builds optimized specifically for Ubuntu, including ultra-slim Chiseled OpenJRE containers aimed at cloud and CI/CD environments. This is another step in a growing trend where the JDK is treated as an artifact tightly coupled to the platform, tooling, and ecosystem around it.

Canonical emphasizes that these builds are significantly smaller - up to 50% smaller than popular distributions like Temurin - without sacrificing throughput or performance.

For JVM developers, this means that the choice of runtime environment is becoming increasingly dependent on deployment context: Ubuntu Pro on servers, IBM Semeru or Red Hat OpenJDK/Quarkus in enterprise setups, Microsoft Build of OpenJDK for Azure, and so on.

As a result, choosing a JDK is no longer simply “just OpenJDK.” It’s becoming more complex, with each provider adding its own twist. Canonical focuses on container size reduction and long-term support; IBM and Red Hat emphasize long-term stability and enterprise application compatibility; Microsoft offers builds tailored specifically for Azure.

What’s interesting is how different organizations now view Java - as a set of composable artifacts fitted to their own ecosystems, rather than as “one universal distribution everyone just downloads and uses.” And that’s the broader trend worth paying attention to.

Hibernate ORM changes its license: The end of the LGPL Era

Hibernate’s license change from LGPL to the Apache License 2.0 also has an interesting broader context. For years, LGPL was “safe enough” for Hibernate. It allowed use in commercial projects, didn’t force companies to open their own code, and in practice rarely caused real problems for engineering teams. The issue is that open source reality doesn’t stop at engineers. In many organizations, the mere presence of LGPL in the dependency tree was enough to trigger a red flag—regardless of how liberal its interpretation actually was. For legal departments, intent mattered less than the license header.

This tension grew as the entire ecosystem evolved. Hibernate давно stopped being a “standalone project” and became a foundation of the modern Java stack: Jakarta EE, Quarkus, and newer initiatives centered around the Commonhaus Foundation. These ecosystems share one common trait: a strong preference for the Apache License as the default standard. LGPL increasingly became an exception - something that had to be explained, justified, and pushed through yet another committee.

In that sense, relicensing was a rational move. The question wasn’t whether LGPL is “bad,” but whether it was still compatible with the direction Java as a platform has taken. Apache License provides simple answers to hard questions: you can use it, distribute it, build products on top of it - without nuances, exceptions, or interpretations - and nobody asks uncomfortable follow-up questions. For projects targeting enterprise adoption - and Hibernate very much is one - that simplicity has real value.

So why go all the way? Because the alternative was slow marginalization. Staying on LGPL would increasingly turn Hibernate into “that problematic component” that blocks adoption, complicates audits, and requires extra explanations.

The license change came with real costs and real losses. It required reaching out to hundreds of contributors across 25 years of project history. It was a test of how “alive” an open-source project really is - one that many people treat as a given part of the landscape. Where consent couldn’t be obtained, code had to be removed or split out. Envers remained under LGPL; other modules simply ceased to exist. Trade-offs were inevitable.

Deno vs Oracle: Who Owns “JavaScript”?

JavaScript is the air of the internet today. A language you don’t really choose—it’s just there. In the browser, on the server, in tools, frameworks, builds, and deploys. And precisely because of that, it can be surprising that, formally, the name “JavaScript” is still a trademark owned by one specific company: Oracle. For years, this was one of those legal oddities everyone knew about, but no one had the time or energy to do anything about. Until the end of 2024.

In November, Ryan Dahl the creator of Node.js and Deno - filed a formal petition with the U.S. Patent and Trademark Office to cancel the “JavaScript” trademark. The starting point is simple: Oracle inherited the mark from Sun Microsystems in 2009, but since then it has not participated in the development of the language, does not take part in TC39, does not sell products based on JavaScript, and in practice has no real connection to it beyond a historical entry in a registry.

The dispute drags on through 2025, with Oracle consistently refusing to voluntarily relinquish the trademark, rejecting the allegations, and attempting to neutralize the heaviest charge - fraud in the renewal of the mark in 2019, when a screenshot of the Node.js website was presented as proof of use. In legal terms, that turns out to be insufficient to prove intentional deception. The rest of the case, however, remains alive, and in September the parties enter the discovery phase - the most expensive and most brutal part of the proceedings.

In the background, something far more interesting is happening than the lawyers’ battle itself. A community that for three decades has treated JavaScript as a common good suddenly realizes that its name does not formally belong to it. An open letter published on javascript.tm gathers tens of thousands of signatures, including that of Brendan Eich - the creator of the language - as well as people who actually shape its evolution today. Deno launches a fundraiser to cover legal costs, because discovery is not paid for with ideals, but with very real money.

I’m writing about this because, in truth, this is not really a dispute about JavaScript itself, but about whether the trademark system should allow the “hoarding” of names that have become technological standards, or whether it should be able to release them once they stop being anyone’s product. Regardless of how the case ends - and we’ll likely wait until 2027 for a verdict - one thing has already happened: someone finally asked out loud whether JavaScript is still someone’s brand, or simply a language that belongs to everyone.

And sometimes, just asking that question is enough to shake the foundations.

Wish you luck, Deno. You will need it.

JetBrains Reveals Plans for a New Programming Language

In July 2025, Kirill Skrygan, CEO of JetBrains, said in an interview with InfoWorld that JetBrains is indeed working on a new programming language. And no - it’s not Kotlin 3.0, nor another iteration of a familiar paradigm. It’s an attempt to jump an entire level of abstraction.

Skrygan described it in a way that almost sounds old-fashioned: through the history of language evolution. First assembly, then C and C++, then Java and C#. Each step moved the programmer further away from the machine and closer to a mental model. The problem is that we’ve been stuck at this level for years. Today’s developers still translate their intent into classes, interfaces, annotations, and frameworks—even though the real design of a system lives elsewhere: in people’s heads, in architecture discussions, in design docs, diagrams, and domain descriptions.

That gap is exactly what JetBrains wants to address. The new language is not meant to be a “better Kotlin,” but an attempt to formalize what has so far been informal: the system’s ontology, the relationships between entities, architectural assumptions, and decisions that today get lost in comments, Confluence pages, or Slack threads - and later have to be manually reconstructed in code. In other words, everything agents need to operate: context.

The most controversial part of this vision appears when Skrygan talks about natural language. The foundation of the new language is supposed to be… English. But not in the sense of “write a sentence and magic happens.” Rather, as a controlled, semantic representation of intent - something between a design document and a formal system description language. AI agents, deeply integrated with JetBrains tooling, would take this description and generate implementations for different platforms: backend, frontend, mobile - everything consistent, everything derived from a single source of truth.

This distinction matters, because Skrygan explicitly distances himself from the popular slogan that “English will be the new programming language.” His view is surprisingly sober: you can’t build industrial systems in plain English. And that tension is key to understanding the whole initiative. JetBrains isn’t trying to replace programming with prompts. It’s trying to build a formal language of intent - one that looks like English but behaves like a programming language. A kind of spec-driven engineering baked directly into the core of the language.

The organizational context also matters. JetBrains is a private company. It doesn’t need to deliver quarterly narratives for the stock market, and it doesn’t have to chase hype. Skrygan says it openly: people are tired of grand AI declarations. And precisely because of that, JetBrains can afford a long-term experiment that may not produce a sellable product for years. It’s the same logic that once allowed them to invest in Kotlin long before anyone knew it would become mainstream.

Importantly, this new language isn’t emerging in a vacuum. JetBrains is already building infrastructure for a world where the IDE is no longer just a code editor. Junie as a coding agent (and yes, we’ll talk more about Junie later), local Mellum models, deep integrations with LLM providers - all of these are pieces of a puzzle in which code stops being the only artifact and becomes just one of many possible “renders of intent.”

We don’t know the timeline. It’s possible that for years we’ll see nothing but prototypes, internal DSLs, and experimental tools - or perhaps nothing at all. But the very decision to think about a new programming language in 2025 (let’s be honest: who even cares about programming languages in 2025?) already says something. JetBrains clearly believes that the next revolution won’t happen in yet another version of Java, Kotlin, or TypeScript, but in a place where we still lack sufficient precision - where code ends and thinking about the system begins.

And since we’re already talking about JetBrains…

The End of the Two - IntelliJ IDEA Era

December 2025 brought a decision that would have seemed unthinkable just a few years ago: the end of the split between IntelliJ IDEA Community Edition and Ultimate. Starting with version 2025.3, there is a single IntelliJ IDEA. Some features are available for free, others require a subscription or a 30-day trial - but the product no longer pretends these are two separate worlds.

For a long time, the Community vs. Ultimate split made sense. Community was a clean IDE for Java and Kotlin; Ultimate was a platform for the enterprise world—Spring, databases, and everything considered “serious.” The problem is that the line between “basic” and “enterprise” has become increasingly blurred. Today, even a student project very quickly touches Spring Boot, SQL, database migrations, or simple web integrations. Keeping these features behind a paywall increasingly stopped being monetization and started becoming frustration - and an onboarding barrier that many simply wouldn’t cross.

At the same time, two products meant two development pipelines, two test suites, two backlogs, and constant decisions about whether a given feature “belongs” in Community or already in Ultimate. In practice, this led to duplicated effort and slowed overall development. Consolidating into a single IDE is, first and foremost, an engineering decision: one codebase, one distribution model, one evolution path. Very Kotlin Multiplatform in spirit.

A (very user-friendly) side effect is the shift in the boundary of free features. Basic support for Spring and Jakarta EE, the Spring Boot wizard, SQL tooling, database connection configuration, and schema browsing suddenly stop being “enterprise-only” features - not because JetBrains became philanthropic, but because without them IntelliJ simply stops being a realistic starting tool for new developers.

But the real reason for this change, in my view, is much more down to earth: pressure from Cursor, Windsurf, Antigravity, and the entire wave of VS Code forks with built-in AI features. When the competition gives you not only a free IDE, but also an intelligent assistant that writes code, refactors, and debugs, the discussion of “should I pay for Spring support?” starts to sound a bit absurd. JetBrains clearly realized that fighting for user base now matters more than optimizing revenue from basic licenses.

Monetization doesn’t disappear - but it shifts dramatically. Instead of selling access to frameworks (especially for quasi-commercial users - companies will buy full IntelliJ anyway), JetBrains will sell AI-assisted development, advanced code analysis, team collaboration, and enterprise tooling. Upselling moves higher up the stack - where real value lies in productivity and scale, not in the mere fact that the IDE “understands Spring.”

This is the end of a certain era (a phrase heavily overused in 2025), but also an open admission of a new reality: if JetBrains wants a chance to compete with free, AI-powered editors, it first has to keep users inside its ecosystem. Limiting basic functionality was only accelerating the exodus to tools like Cursor. From 2025 onward, there is one IntelliJ. And this isn’t a gesture of goodwill, but a necessity in today’s world. That is what industry expects right no

WASM for the JVM Is Gaining Momentum

WebAssembly is one of those standards that has been circulating in industry narratives for years like Death in Venice - everyone knows it’s about to take off, it’s just that the “any moment now” keeps getting postponed.

(Sorry for the slightly hermetic Polish literary joke - couldn’t resist.)

And yet, looking at what’s happening today in the JVM ecosystem, it’s hard to shake the feeling that WASM is finally starting to find its place - and in several interesting niches at once.

The most obvious signal is GraalVM, which is increasingly treating WebAssembly not as an exotic target, but as one of the first-class ways of executing code. WASM in Graal’s incarnation is not trying to replace the JVM or AOT in the style of Native Image — instead, it offers yet another secure sandbox that Java can interact with on its own terms.

In parallel, a completely different approach is emerging, represented by CheerpJ. This line of thinking doesn’t ask “how do we port Java cleanly to WASM?” but rather “how do we make existing JVM applications simply run in the browser?” — without rewriting, without porting, without months-long migrations. CheerpJ demonstrates that WebAssembly can act as a compatibility layer - something akin to a modern JRE for the web world. It’s a highly pragmatic vision, especially for old, heavy desktop applications that suddenly get a second life in the browser.

On top of that comes Kotlin, which for a long time has treated the web as a first-class platform rather than merely a “frontend to a backend.” In JetBrains’ latest plans, WASM is increasingly visible as a real alternative to JavaScript in places where predictability, performance, and consistency of execution models matter. This is not a mass movement yet, but the direction is clear: Kotlin/Wasm is not meant to compete with JavaScript in writing widgets, but in building serious web applications that don’t want to inherit the full baggage of the browser ecosystem.

The most interesting pieces, however, are projects that show WASM from the inside. One of my favorite spikes of the year is the story of porting the Chicory WebAssembly runtime to Android. It’s a great example of the fact that WebAssembly is not a magical format that solves all problems. Quite the opposite — it forces very deliberate thinking about memory, ABI, execution models, and host integration. And that’s precisely why it fits the JVM so well: a platform that has lived for decades at the intersection of high-level abstraction and hardcore runtime engineering.

Taken together, this paints an interesting picture. WASM in the JVM world is not a “new JVM” trying to replace bytecode or HotSpot. Instead, it’s another universal execution format that can be plugged in wherever isolation, portability, or execution in previously inaccessible environments is required. Browser, edge, sandbox, mobile - in all these places, WASM can serve as a natural bridge.

And perhaps that’s exactly why this time WebAssembly really does have a chance to take off. Not as a hype-driven replacement for everything, but as a missing puzzle piece. JVM, being the JVM, doesn’t rush into WASM with startup-style enthusiasm - it approaches it methodically, calmly, and with full awareness of its limitations. And Java’s history suggests that this is usually the best predictor of long-term success.

However we need to remember world looks a bit different nowadays.

TornadoVM Is having the time of its life

For years, TornadoVM was one of those projects everyone “had on their radar,” but few treated as anything more than an academic curiosity - fitting for a project coming out of the University of Manchester. Java on GPUs, FPGAs, and accelerators? It sounded like a future that was always one conference too far away. The year 2025 very clearly changed that picture. TornadoVM stopped being a promise and started to look like a technology that has genuinely found its place in the JVM ecosystem, addressing concrete needs of the platform.

One of the most symbolic signals of this shift was a personnel move. Juan Fumero, one of the leaders of the TornadoVM project and the public face of the BeeHive Lab at the University of Manchester, joined the Java Platform Group at Oracle. This is the moment when an experimental research project meets, directly, the team responsible for the future of OpenJDK. It’s hard to imagine a clearer sign that JVM acceleration is no longer a side topic.

The strongest signal of TornadoVM’s “entry into the real world,” however, turned out to be GPULlama3.java. Running LLaMA on GPUs without leaving the Java ecosystem, without writing CUDA, and without manual memory management is something that would have sounded like clickbait just two years ago. The 0.2.0 release of the project proved that TornadoVM is not only capable of handling simple kernels, but can also support real AI workloads.

What’s crucial here is that TornadoVM never tried to compete with GraalVM, CUDA, or OpenCL on the level of “who’s faster.” Its ambition was different: to let JVM developers think in terms of tasks and data, rather than threads, blocks, and registers. In this context, TornadoVM 2.0 (which I will cover more deeply in January) looks like the transition point from a research prototype to a platform. A more stable programming model, better integration with the JVM, real support for GPUs, CPUs, and accelerators - and, above all, less magic and more predictable contracts. This is exactly the moment when a project stops living only in academic papers and starts living in production repositories.

The most interesting question is no longer “does TornadoVM make sense,” but rather: when will we see its DNA in OpenJDK? Perhaps not as a ready-made framework, but as APIs, abstractions, and a direction for JVM evolution prepared for a world where the CPU is just one of many places where code runs.

Seen more broadly, TornadoVM fits perfectly into a moment in which Java is once again redefining its boundaries. Not by changing syntax, but by changing where and how code is executed. And perhaps for the first time in a long while, hardware acceleration in Java no longer looks like an experiment.

TornadoVM has truly come into its own.

BTW: We had a guest appearance post in the December about TornadoVM Architecture - I consider it the essential lecture for 2026 😁

Project Stargate Becomes Oracle’s New Darling

At first glance, Project Stargate looks like something completely outside our bubble. OpenAI, SoftBank, gigantic data centers, hundreds of billions of dollars, and a narrative straight out of AI geopolitics. It’s hard to imagine anything further removed from the JVM, GC, and JDK releases. And yet - if you look more closely - Oracle shows up in this story in a way that makes it entirely reasonable to talk about it right here.

In January 2025, OpenAI and SoftBank announced Stargate: a long-term project to build hyperscale computing infrastructure for AI, ultimately valued at as much as several hundred billion dollars. The goal is not a single data center, but a global network of facilities designed from the ground up for training and inference of large models. It’s an attempt to create an “intelligence factory” - infrastructure positioned as a strategic asset… all based on GPUs from Nvidia.

And this is where Oracle enters the picture, as a real operator and cloud provider. Oracle Cloud Infrastructure is meant to be one of the pillars of Stargate - both technologically and operationally. This is a very interesting turn, because for years Oracle was perceived more as a databases-and-enterprise-legacy company than as a player shaping the AI compute race. Stargate shows that this perception is becoming increasingly outdated.

From a JVM perspective, this is still very much a “side topic.” Stargate is not about Java, bytecode, or HotSpot, but about GPUs, networks, power, cooling, and decades-long contracts. At the same time, it involves the same company that owns the JavaScript trademark, develops OpenJDK, pushes Valhalla, Leyden, and Babylon, and makes enormous amounts of money on enterprise Java. Oracle is playing on several boards at once - and Stargate illustrates the scale of that game.

Project Stargate is a story about just how much the landscape around the JVM is changing. About how companies that spent decades building stable, boring IT foundations are now also players in the most capital-intensive and futuristic technology race of our time.

And even if the JVM stands a bit off to the side here, Oracle - somewhat atypically for itself - is standing very close to the center of the stage. It will be interesting to see how much of this we’ll start to notice over the coming year.