JDK 26 ships on March 17. Project Valhalla just entered preview. Post-quantum TLS is targeted for JDK 27. The JVM is moving faster than it has in a decade — and every one of these trends has real consequences for production code today.
Java turned 30 in 2025, and rather than slowing down, the platform accelerated. JDK 25 shipped as the latest LTS in September 2025, Spring Boot 4.0 arrived in November, Spring AI reached 1.0 in May, and a cadre of long-running OpenJDK projects — Valhalla, Leyden, Loom, Panama, Amber — all hit meaningful milestones. JDK 26 is two days away from general availability. Here are the five trends that will define what you build and how you build it for the rest of this year.
1. Value Classes Are Finally Here — and They Change How Java Models Data
Of all the long-running OpenJDK projects, Project Valhalla has had the longest preview runway and the most transformative implications. After years of incubation, JEP 401 — Value Classes and Objects was targeted for JDK 26, marking the first time value classes become available in a standard JDK build. As of October 2025, early-access builds were already shipping implementing value classes with the preview flag.
The core idea is elegant and consequential. A value class is an object that has no identity — two value instances with the same field values are indistinguishable, just as two int literals 42 and 42 are indistinguishable. This allows the JVM to bypass the overhead of object identity: no synchronisation on this, no identity hash code, no requirement for heap allocation. The JIT can inline value objects directly into arrays and other structures, eliminating the pointer indirection that makes Java arrays of objects cache-unfriendly compared to C or Rust.
Value classes must contain only final fields, cannot be extended, and cannot be the operand of synchronized or identity-sensitive operations like == on references. In exchange, you get objects that the JVM can treat — and optimise — much like primitives.
// JDK 26 preview — value class declaration
value class Point(double x, double y) {
public double distanceTo(Point other) {
double dx = this.x - other.x;
double dy = this.y - other.y;
return Math.sqrt(dx * dx + dy * dy);
}
}
Why it matters for your team: The immediate beneficiaries are data-intensive applications — financial services modelling complex instruments as objects, scientific computing, game engines, and any code that currently boxes primitives into wrappers like Integer or Double to store them in collections. Java Code Geeks’ 2026 outlook estimates realistic production readiness by JDK 26–27, meaning teams should start evaluating the preview now and planning migration paths for performance-critical data models.
Additionally, value classes are what JEP 500 (Final Field Integrity) was partly building towards. When final fields are guaranteed to be truly immutable — which JEP 500 enforces starting with warnings in JDK 26 — the JVM can make more aggressive constant-folding assumptions about value class instances. The two JEPs reinforce each other, and teams adopting value classes should ensure their codebases comply with JEP 500’s restrictions simultaneously.
2. HTTP/3 Lands in the Standard Library — The End of HTTP/2-Only Java Networking
Java’s HttpClient, introduced in JDK 11 and significantly improved since, finally gains native HTTP/3 support in JDK 26 via JEP 524. This is not a preview feature — it is a direct upgrade to the standard java.net.http package. As InfoWorld describes it, the proposal calls for allowing Java libraries and applications to interact with HTTP/3 servers with minimal code changes, requiring only minor modifications to existing HTTP Client API usage.
HTTP/3 is built on QUIC — the IETF transport protocol that moves from TCP to UDP while adding flow-controlled streams, low-latency connection establishment, multiplexing without head-of-line blocking, and native TLS 1.3 integration. For microservices teams, the practical implication is significant: HTTP/3 eliminates the head-of-line blocking problem that affects HTTP/2 multiplexing at the TCP layer, and its connection migration capability means mobile or roaming clients can maintain connections across network changes without reconnecting.
// Opt in to HTTP/3 in JDK 26 — no API change required
HttpClient client = HttpClient.newBuilder()
.version(HttpClient.Version.HTTP_3) // new constant
.connectTimeout(Duration.ofSeconds(10))
.build();
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create("https://api.example.com/data"))
.GET()
.build();
HttpResponse<String> response =
client.send(request, HttpResponse.BodyHandlers.ofString());
Developer opt-in by design: HTTP/3 is not set as the default — you explicitly request it with HttpClient.Version.HTTP_3. The JDK negotiates the appropriate version with the server; if the server does not support HTTP/3, the client falls back gracefully. This means existing code continues to work without change, and teams can adopt HTTP/3 incrementally on routes where the latency benefits are most valuable.
Looking ahead, JEP 527 — Post-Quantum Hybrid Key Exchange for TLS 1.3 is already targeted for JDK 27 (September 2026), building on the quantum-resistant Module-Lattice-Based Key Encapsulation Mechanism delivered in JDK 24. Together, HTTP/3 support and post-quantum TLS represent a coherent modernisation of Java’s networking security model that will matter enormously for any application exchanging sensitive data with clients over untrusted networks.
3. The JVM Becomes a First-Class AI Platform — Not Just an LLM Client
The most strategically significant shift in the Java ecosystem in 2025–2026 is not a JEP. It is the arrival of a coherent, production-grade AI development stack on the JVM — one that stops treating AI as a Python capability that Java has to call over HTTP, and starts treating the JVM as the right place to build and deploy AI agents for enterprise workloads.
Three developments in quick succession mark this shift. Spring AI 1.0, released in May 2025, delivers a ChatClient interface supporting 20 AI models with multi-modal inputs, an Advisors API for injecting retrieval data and conversation memory into prompts, and full Model Context Protocol (MCP) support. The InfoQ Java Trends Report for 2025 places Spring AI 1.0 squarely in the “Early Majority” adoption tier — meaning it is no longer experimental. The MCP Java SDK, introduced in December 2024, enables Java applications to interact with AI models and tools through a standardised interface supporting both synchronous and asynchronous communication. And as we covered earlier in this series, Embabel (Rod Johnson) and Koog (JetBrains) brought native JVM agent frameworks with goal-oriented planning and coroutine-based execution respectively.
JFR meets AI: Dev.java’s March 2026 updates highlight a new session titled “Intelligent JVM Monitoring: Combining JDK Flight Recorder with AI” — demonstrating how live JFR data can be streamed into an AI system for real-time anomaly detection, self-improving application behaviour, and predictive issue prevention. This is a concrete example of AI and JVM tooling converging, not just coexisting.
| Tool / Framework | Released | Key capability | Adoption tier |
|---|---|---|---|
| Spring AI 1.0 | May 2025 | 20 model providers, Advisors API, MCP, vector stores, RAG pipeline | Early majority |
| MCP Java SDK | Dec 2024 | Standardised AI tool/model protocol; sync + async | Innovators |
| Embabel | 2025 (v0.3.4) | GOAP planning, Spring-native, @Agent / @Action / @Goal | Innovators |
| Koog | 2025 (v0.6.4) | Graph-based strategy, coroutines, Kotlin Multiplatform, checkpointing | Innovators |
| LangChain4j | Ongoing | Lower-level LLM primitives; broad model support; RAG tooling | Early adopters |
For enterprise Java teams, the implication is clear: the question is no longer whether to add AI capabilities to JVM applications, but which layer of the stack to integrate at. Spring AI is the pragmatic entry point. Embabel and Koog are for teams building serious multi-step agent workflows on the JVM. LangChain4j bridges teams that need maximum model coverage and flexibility at the primitive level.
4. Project Leyden Is Fixing Java’s Startup Problem — Without Graal
Java’s reputation for slow startup and high memory footprint has long been the argument for reaching for Go, Rust, or native compilation when building serverless functions, CLI tools, or container-packed microservices. Project Leyden is the OpenJDK effort to fix this within the standard JVM — no separate compiler required, no native image build step, no reduced feature set.
As InfoQ’s 2025 trends report confirms, the first three Leyden features landed in JDK 24 and JDK 25, with a fourth targeted for JDK 26. The approach is based on Ahead-of-Time (AOT) class loading and linking — the JVM builds a cache of pre-processed class files, resolved class hierarchies, and pre-compiled JIT output on first run, then reuses that cache on subsequent runs without repeating the work. JDK 26 specifically targets making AOT caching compatible with all garbage collectors (JEP 483), whereas earlier versions only worked with specific GCs.
# Training run: build the AOT cache (JDK 26)
java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf \
-cp app.jar com.example.Main
# Subsequent runs: load from cache
java -XX:AOTMode=on -XX:AOTConfiguration=app.aotconf \
-cp app.jar com.example.Main
# Result: dramatically reduced class loading, linking, and JIT warmup time
Concurrently, JEP 531 — Lazy Constants (Third Preview), formerly known as Stable Values, was elevated to Candidate status in February 2026. Lazy Constants allow fields to be initialised exactly once on first access and then treated as compile-time constants by the JIT — enabling aggressive constant folding without requiring static final initialisation at class load time. The JDK 26 iteration renamed the factory to ofLazy() and removed methods that conflicted with the design, tightening the API towards eventual finalization.
Leyden vs GraalVM Native Image: GraalVM Native Image remains the most aggressive startup optimisation available for JVM applications — producing executables with near-instant startup and minimal memory footprint. But it comes with significant trade-offs: closed-world assumption requires ahead-of-time metadata for all reflective code, debugging is harder, and some JVM features are restricted. Project Leyden targets the middle ground: meaningful startup and warmup improvement without leaving the standard JVM or sacrificing dynamic capabilities. InfoQ notes GraalPy and GraalWasm moved to “stable for production” in GraalVM for JDK 23 — both approaches are maturing simultaneously, and teams should choose based on their tolerance for the GraalVM trade-offs.
5. Modern Java Syntax Is Reaching Mainstream — And Spring Boot 4 Demands It
The fifth trend is less about a single feature and more about a critical mass moment. The language improvements that Java developers have been previewing since JDK 16 — sealed classes, pattern matching for instanceof, pattern matching in switch, records, and now primitive types in patterns — have collectively crossed a threshold in 2025–2026 where using them is no longer avant-garde. It is the expected baseline for modern Java code.
Spring Boot 4.0, released in November 2025, sets this expectation institutionally. It requires JDK 17 as a minimum, makes null-safety annotations from JSpecify a first-class concern, ships API versioning natively, and aligns with Spring Framework 7.0’s push towards more functional, declarative programming styles. InfoQ’s trends report notes this as a signal: major libraries are actively requiring relatively current JDK versions, accelerating the pace at which the ecosystem moves.
In JDK 26 specifically, primitive types in patterns (JEP 488, fourth preview) extends pattern matching to cover precise representation checks across primitive types. Where reference type patterns match subtypes, primitive patterns check whether a value of one primitive type can be represented by another without loss of precision:
// JDK 26 preview — primitive type pattern matching
void describe(double value) {
switch (value) {
case int i -> System.out.println("Whole number: " + i);
case float f -> System.out.println("Single precision: " + f);
default -> System.out.println("Full double: " + value);
}
}
// Pattern matching for instanceof — now standard (since JDK 16)
if (shape instanceof Circle c && c.radius() > 0) {
System.out.println("Area: " + Math.PI * c.radius() * c.radius());
}
Jakarta EE 12 on the horizon: InfoQ reports that Jakarta EE 12 work commenced in early 2025, with 24 specification reviews underway and four new specifications already added to the ecosystem — including Jakarta Query. The anticipated release is July 2026. Jakarta EE 11 has already been certified by Open Liberty, WildFly, Payara, and GlassFish. For teams on the Jakarta EE track, 2026 is the year to plan both the EE 11 and EE 12 migration paths simultaneously to avoid doing the work twice.
The broader pattern across all five trends is consistent: the Java platform in 2026 is not the Java of 2018. The six-month release cadence has enabled a sustained, incremental improvement curve that, taken together, produces a language and runtime that is genuinely competitive with newer alternatives — not despite its backward compatibility, but partly because of it. Every trend listed here builds on existing Java knowledge while extending its reach. That is a rare combination in platform evolution, and it is why, as iCert Global’s 2026 guide notes, 99% of organisations continue to rely on Java for core systems even as the landscape of alternatives has never been more crowded.
Key JEP milestones across JDK 24–27: from preview to finalization
Trend readiness vs production impact — where each trend sits today
6. What We Have Learned
Java in 2026 is defined by convergence — multiple long-running research projects arriving at practical usability simultaneously. Project Valhalla’s value classes eliminate the identity overhead that has made value types second-class citizens on the JVM since 1995. HTTP/3 and post-quantum TLS bring Java networking into alignment with the current security and performance landscape. The arrival of Spring AI 1.0, the MCP Java SDK, Embabel, and Koog closes the gap between Python’s AI ecosystem and the JVM, without asking teams to leave the platform where their business logic already lives.
Project Leyden delivers meaningful startup and warmup improvements through AOT caching — a pragmatic alternative to the native image trade-offs that many teams have been reluctant to accept. And the combination of modern language features from Project Amber reaching critical mass, Spring Boot 4 raising the baseline, and Jakarta EE 12 approaching completion signals that the surrounding ecosystem is moving at the same pace as the core platform. Taken together, these five trends make the case that the JVM in 2026 is not catching up — it is setting the agenda.
The teams that invest in understanding these changes now, rather than waiting for final releases, will ship better-performing, safer, and more capable applications by the end of the year.
