Java in April 2026: Leyden Grows Up, Spring Gets Smarter, and the JVM Quietly Reinvents Itself for the AI Era

Turker Senturk
Software
17 Apr, 2026
15 min read

If you’ve been half-watching the Java world from the sidelines over the last few years, April 2026 is a good moment to look up. Java 26 shipped in March, the frameworks are catching up fast, and the parts of the ecosystem that felt like awkward bolt-ons a year ago — AI integration, fast container startups, sensible null-safety — are starting to feel like they actually belong.

This isn’t a “Java is back” piece. Java never really went anywhere. It’s more that a bunch of long-running projects are finally paying off at roughly the same time, and the first half of April gave us a pretty clear snapshot of what that looks like in practice.

Let’s walk through it.

The JDK itself: Java 26 moves the cold-start needle

Java 26 reached general availability on March 17, 2026, right on the six-month cadence Oracle has been hitting with boring regularity for years now. It’s a non-LTS “feature release” — Java 25, released in September 2025, is still the current LTS — but as short-term releases go, this one punches above its weight.

The release ships with ten JEPs, spanning language improvements, garbage collection upgrades, security enhancements, and more. No splashy new language syntax this time around. Instead, Java 26 is mostly about making the platform faster, cleaner, and easier to run at scale.

The headline feature, for anyone who’s ever watched a Kubernetes pod sit there for an embarrassingly long time before serving its first request, is JEP 516: Ahead-of-Time Object Caching with Any GC.

This is the latest piece of Project Leyden — OpenJDK’s long-running effort to shrink the gap between “the JVM starts” and “the app is actually useful.” The basic idea: the JVM does a lot of work on every startup. A typical Spring Boot application touches somewhere between 15,000 and 25,000 classes by the time it’s fully initialised. Leyden’s answer is to record as much of that work as possible during a training run and replay it on every subsequent start.

JEP 516 extends that cache to work with any garbage collector, including ZGC. Previous iterations of the AOT cache stored object references as literal memory addresses, and because ZGC’s unique reference format differs so fundamentally from standard pointers, the existing AOT cache was incompatible. Java 26 fixes that with a clever bit of engineering: objects are now stored in a GC-neutral format and materialized at startup by a background thread.

What this means in practice: teams that need ZGC’s sub-millisecond pause times no longer have to give up AOT caching to get it. That was a genuinely painful trade-off before. The real-world numbers are still dependent on the workload, but the Project Leyden team has reported Spring PetClinic — a common benchmark — starts 41% more quickly in production because the cache enables some 21,000 classes to appear already loaded and linked when the application starts.

That’s not native-image territory, but it’s very close, and unlike GraalVM Native Image, you don’t have to give up the JIT or rewrite any of your code to get it.

A few other bits worth knowing about Java 26:

The G1 garbage collector now eagerly reclaims eligible humongous objects containing references, allowing prompt recovery of memory previously held by such objects, particularly if they are short-lived.
JEP 517 brings HTTP/3 support to the HTTP Client API, allowing libraries and applications to interact with HTTP/3 servers with minimal code changes.
Structured concurrency and lazy constants (renamed from “stable values” in Java 25) continue to mature as preview features.
The Applet API is finally gone. Pour one out.

JDK 27 is already on the horizon for September 2026. Early targeted JEPs include post-quantum TLS key exchange, more Leyden work, and — if the stars align — a preview of Project Valhalla’s value classes, which would be the biggest change to Java’s object model since generics.

Spring Boot 4: the rough edges are getting sanded down

Spring Boot 4.0 itself shipped back in November 2025, so it’s not news anymore. But the first half of April 2026 has been interesting because the post-GA dust is settling, and you can now see what the upgrade actually looks like for teams doing it for real.

The current version as of mid-April is Spring Boot 4.0.5, which was released on March 26, 2026. There’s also a 4.1.0-M4 milestone out, pointing toward the next minor release expected around May.

Here’s the thing about Spring Boot 4: the marketing framing of “next generation” would normally raise eyebrows, but this time it’s more accurate — the release modularises the entire Spring Boot codebase into 70+ focused JARs, mandates Jackson 3 as the JSON library, and ships three significant additions that change how you’ll write Java APIs going forward. The big ticket items:

Jakarta EE 11 baseline. Spring Boot 4.0 targets Jakarta EE 11 and requires a Servlet 6.1 compatible container.
JSpecify null-safety. Every part of Spring is now annotated for null-safety in a way that IDEs and tools like NullAway can actually reason about.
Built-in API versioning. No more cobbling together path-segment versioning with @RequestMapping gymnastics.
Jackson 3 as default. This one has a sharp edge: Jackson 3’s default for WRITE_DATES_AS_TIMESTAMPS is false, producing ISO-8601 strings, whereas Jackson 2 defaulted to Unix timestamps. If your client code or snapshot tests assert on timestamp format, they’ll break silently in production after the upgrade. Audit your date fields before you cut over.

Java 17 remains the baseline — a deliberate call reflecting what teams are actually running — but Java 21 and Java 25 are strongly recommended if you want virtual threads and the newer JVM features to pay off.

One thing worth noting for anyone still procrastinating: Undertow support is gone in 4.0 because Undertow doesn’t yet support Servlet 6.1. If you’re on Undertow, that’s a migration to plan for, not a “next sprint” thing.

Micronaut keeps shipping, quietly

While Spring grabs the headlines, Micronaut has been doing the steady, weekly-update grind that nobody talks about but that actually matters for production teams.

Micronaut framework 4.10.11 was released on April 1, 2026, containing releases of Micronaut Core, Micronaut Logging, and Micronaut OpenAPI. That’s on top of 4.10.10 a couple of weeks earlier, which included security advisories fixing potential denial-of-service attacks — a DoS via crafted form-urlencoded body binding with descending array indices. If you’re on any 4.10.x version earlier than that, upgrade.

Micronaut’s pitch has always been compile-time dependency injection and minimal reflection, which translates to fast startup and low memory overhead. That pitch ages well in 2026 — it’s essentially the same direction Leyden is pushing the JVM itself, just from a different angle. The fact that Micronaut keeps shipping focused patches every couple of weeks is arguably more impressive than another “next-gen” major release with a big launch post.

Jakarta EE 11, Open Liberty, and the quietly impressive spec story

Here’s a plot twist most developers would have laughed at five years ago: Jakarta EE is actually interesting again.

Jakarta EE 11 landed in 2025, and April 2026 is when the implementations really start catching up with the whole platform. Open Liberty 26.0.0.4-beta dropped on April 7th, and the release notes read like a checklist of things the enterprise Java community has been asking for:

This beta introduces Jakarta EE 11 Platform and Web Profile, and delivers enhancements across Jakarta Authentication 3.1, Jakarta Authorization 3.0, and Jakarta Security 4.0. In addition, it provides a preview of Jakarta Data 1.1 M2, support for Java 26, MCP Server updates, and Jandex index improvements.

That last item is worth pausing on. MCP Server updates — as in Anthropic’s Model Context Protocol — in a Jakarta EE reference implementation. Open Liberty has been quietly building first-class MCP support as a Liberty feature, and the latest beta tightens that up considerably.

Meanwhile, Jakarta EE 12 is targeted for H1 2026 and will require Java 21 as a baseline with Java 25 at runtime. Key new specs include Jakarta Query 1.0, Jakarta NoSQL 1.1, and Jakarta MVC 3.1. Work is also underway on Jakarta Agentic AI — a vendor-neutral API set for building and deploying AI agents on enterprise Java. (Realistically, the EE 12 GA date has slipped — the compromise landing spot is now “by the end of 2026,” with deliberations ongoing.)

The Jakarta Agentic AI spec is the part that matters for the bigger picture. For the first time in a long time, the enterprise Java world is trying to be first to a major trend rather than catching up to it. Whether the spec lands as something people actually use is a different question, but the intent is interesting.

AI on the JVM: the “you don’t need a Python sidecar” moment

This is where April 2026 gets genuinely exciting. For years, the honest answer to “how do I add an AI agent to my Java backend?” was some version of “stand up a Python service and call it over HTTP.” That era is wrapping up.

Three things converged in the last few weeks that collectively make the JVM a real place to build AI applications.

Spring AI 1.1.4 and 2.0.0-M4

On March 26, 2026, the Spring team pushed Spring AI 1.0.5, 1.1.4, and 2.0.0-M4 all on the same day — a combined 51 improvements, bug fixes, and documentation updates across three release streams. The 2.0.0-M4 milestone is the interesting one: it’s where the future lives, rebuilt on Spring Boot 4 and Spring Framework 7 with a Jakarta EE 11 baseline.

The big story for Spring AI 1.1 (which went GA back in November 2025) is the Model Context Protocol integration. Spring AI provides Spring Boot auto-configuration and a comprehensive annotation-based programming model for MCP integration. You can annotate a method @McpTool and expose it to any LLM that speaks MCP. You can annotate another one @McpResource and the model can pull it in as context. It’s the kind of thing that would’ve required three libraries and a lot of YAML a year ago.

Spring AI 1.1 GA shipped on November 12, 2025, after a development cycle that accumulated over 850 improvements across five milestone builds and an RC. That level of churn tells you something about where the team is putting energy.

JetBrains Koog lands for Java

This one genuinely surprised me. JetBrains quietly released Koog for Java on the same day Java 26 shipped — March 17, 2026. Koog started life as a Kotlin framework for AI agents (originally built for JetBrains’ own internal use as it scaled up its AI products), and now there’s a fully idiomatic Java API. Java teams can build reliable AI agents directly inside existing backends, with fluent builder-style APIs, thread pool executors, and native Java abstractions — completely free of Kotlin-specific friction.

Koog’s pitch is different from Spring AI’s. Spring AI is the integration layer — connect to your model, pull context from your vector store, expose tools. Koog sits one level up and focuses on orchestration: how the agent actually executes a multi-step task, what happens when a step fails, how you persist state so you can resume a crashed agent without replaying every expensive LLM call.

Koog’s role is not to replace Spring AI, but rather to add a stronger agent runtime, offering multi-step strategies and workflows, persistence and checkpoints for fault-tolerant execution, sophisticated history management for cost-optimization, and automated deterministic planning.

There’s already a JetBrains-authored integration that lets you use Koog on top of your existing Spring AI setup, so you can keep your model providers and vector stores where they are and just add the orchestration runtime. That’s the kind of quality-of-life integration that used to take the ecosystem years to converge on.

LangChain4j: the quiet workhorse

Meanwhile, LangChain4j keeps doing what it does: being the JVM port of the most popular Python AI framework, but built with actual Java idioms rather than a Pythonic API grafted onto the JVM. The library has shipped deeper CDI support for Jakarta EE and continues to add integrations for hybrid search and enterprise vector databases. It’s less flashy than Spring AI, but for teams that don’t want to commit to the Spring ecosystem, it’s become the default choice.

Stacked together, Spring AI + Koog + LangChain4j mean that Java developers in April 2026 have roughly the same toolkit for agentic AI as Python developers do — minus the requirement to stand up a separate service in a language your team might not speak.

The data layer: Hibernate 7 and the Virtual Threads story

On the persistence side, Hibernate 7 continues to roll out. It targets Jakarta Persistence 3.2 and takes advantage of Java 21+ features like records and virtual threads. The query engine has been reworked to take better advantage of the newer JVM idioms, and integration with Jakarta Data — the new repository-pattern spec — is coming along.

Virtual threads deserve a separate note. They’ve been stable since Java 21 (September 2023), but the ecosystem is still sorting out the subtleties. The most interesting ongoing work is in Project Reactor, where the team is building bridges between reactive programming and virtual threads rather than positioning them as competing paradigms. The short version: use virtual threads for straightforward request-per-thread workloads where the code is linear, and keep reactive for pipelines where you genuinely need backpressure, composition, and non-blocking flow control. The tooling is finally letting you mix the two without the impedance mismatch that made earlier attempts painful.

Cloud vendors: Corretto 26 and the rest of the race

The cloud vendors all moved in lockstep on Java 26 support this time around. Amazon Corretto 26 is now generally available, downloadable for Linux, Windows, and macOS, and it’s a drop-in replacement for other OpenJDK builds. One thing to be careful about: some coverage has called Corretto 26 an LTS release, but Amazon’s own FAQ is clear that Corretto 26 is a Feature Release, with GA on March 17, 2026, last planned update in July 2026, and end-of-life in October 2026. If you want LTS from Amazon, stay on Corretto 25.

Oracle also used the Java 26 launch to introduce the Java Verified Portfolio, a curated set of supported tools, frameworks, and libraries. The new Oracle Java Verified Portfolio provides support for customers’ broader Java application and development stacks, with commercial support for JavaFX and Helidon available. It’s a sensible commercial play — the kind of thing large enterprises keep asking for — but for most of us building applications, it changes very little day-to-day.

Where Java sits right now

Here’s a cheat-sheet of the “what’s actually running?” question for April 2026:

Layer	Current stable	What’s interesting in April 2026
JDK	Java 25 LTS / Java 26 FR	JEP 516 brings AOT caching to ZGC; Valhalla getting closer
Spring Boot	4.0.5 (4.1 on the way)	Jackson 3 defaults, JSpecify null-safety, API versioning
Micronaut	4.10.11	Weekly patches; security advisories in 4.10.10
Jakarta EE	EE 11	Open Liberty 26.0.0.4-beta delivers full platform support
Spring AI	1.1.4 / 2.0.0-M4	MCP integration is now first-class
Koog	0.7.3	Native Java API released March 17
Hibernate	7.0.x / 7.1.8	Virtual thread–friendly, Jakarta Persistence 3.2
Kotlin	2.3.x	K2 compiler stable, Java 26 feature parity

Java’s TIOBE ranking, for what that’s worth, sits at #4 in March 2026 with 7.99%, behind Python (21.25%), C (11.55%), and C++ (8.18%). The index is a noisy signal, but the direction matters more than the rank: Java is still the default choice for enterprise backends, the ecosystem is shipping at a healthy pace, and the long-running investments (Leyden, Valhalla, virtual threads) are actually arriving.

The Techlife verdict

April 2026 isn’t a dramatic month for Java — it’s a boring month, in the best possible sense. The spectacular announcements happened in March: Java 26 GA, Koog for Java, the Spring AI 1.1.4 / 2.0.0-M4 drop. What April is doing is letting it all bed in.

That’s important, because Java’s reputation for stability was built on exactly this pattern: big things ship, the ecosystem absorbs them, and the follow-up patch releases smooth out the edges. When I say “boring,” I mean that in the same way a bridge you drive across every day is boring. You want that.

The bigger story, if you zoom out: Java in April 2026 is no longer the language you pick because it’s “what the team knows.” It’s a genuinely competitive choice for cloud-native workloads (thanks Leyden), for AI applications (thanks Spring AI, Koog, LangChain4j), and for the kind of long-running enterprise systems it’s always been good at. The question “why are you writing this in Java?” now has real answers beyond historical inertia.

Whether that’s enough to pull new teams onto the JVM against the gravitational pull of Python and TypeScript is a different question. But for the millions of developers already there, the ecosystem has rarely looked healthier.