Java 26 is expected around March 2026. As a non-LTS release between JDK 25 and the next LTS (27 or 29), it won’t be the release most production shops jump to immediately — but several features are worth paying attention to because they’ll land in the next LTS. This article is an early look based on the JEPs at candidate or proposed-to-target status as I write this.

Note: I’m writing this before the release, so specifics may shift. Treat it as a preview of what’s likely, not a reference manual.

What’s (likely) going final

Primitive Types in Patterns

Patterns that check and convert primitives, not just reference types:

Object value = readFromSomewhere();

String desc = switch (value) {
    case int i -> "int: " + i;
    case long l when l > Integer.MAX_VALUE -> "big long: " + l;
    case double d -> "double: " + d;
    case String s -> "string: " + s;
    default -> "other";
};

Makes working with unboxed numeric types in switch far more ergonomic.

Compact Object Headers (default-on expected)

Currently experimental in 25, this change reduces object header size from 12-16 bytes to 8 bytes on 64-bit JVMs.

Real numbers from early benchmarks:

  • Heap usage: 5-15% smaller on typical backends
  • GC pressure: proportionally lower
  • Cache locality: measurably improved on data-heavy workloads

For services with many small objects (event processors, serialization-heavy APIs), this is free performance. For others, the win is a modest but consistent heap reduction.

Scoped Values ergonomics

Scoped Values went final in 25, but 26 smooths edges:

  • Better integration with Thread.Builder
  • More examples in the standard library using them
  • Cleaner interop with StructuredTaskScope

Module Import refinements

Small improvements to the compact source file workflow — more useful for scripts and tooling, not production services.

What’s at preview / incubator

Value Classes and Objects (Project Valhalla — still preview, possibly next iteration)

The long-awaited “value classes” — classes that behave like primitives (no identity, can be flattened in memory) but look like classes:

value class Point {
    int x; int y;
}

// In arrays, stored inline instead of as references
Point[] points = new Point[1_000_000];

For numeric / geometry / financial code, this could be a 2-5× memory reduction. Still preview; likely not fully cooked for 26.

Generics over Primitives (Valhalla)

List<int> — typed generics without boxing. Still in the labs but the direction is clear.

Async Stack Traces

Better stack traces for code using CompletableFuture and virtual threads. Today’s async stack traces are notoriously unhelpful; the proposed improvements thread more context through for better debugging.

Stream Improvements

Further gatherers, better parallel performance, cleaner integration with Flow reactive streams.

Things being deprecated / removed

Security Manager (finalized deprecation) The Security Manager has been deprecated for removal since JDK 17. JDK 26 may accelerate the timeline. If your code still uses it, migrate now.

Older elliptic curve implementations Several legacy crypto curves are being removed. If you’re on outdated crypto, check compatibility.

Unsafe cleanup sun.misc.Unsafe continues its slow death. Most libraries have migrated to VarHandle; if yours hasn’t, you’ll notice warnings escalate.

Performance trajectory

Generational ZGC and the compact-headers change together mean 26 will likely show continued “just upgrade” gains of 5-10% throughput over 25. This has been the story since JDK 17 — each release extracts more from the same code.

Should I upgrade?

For libraries and SDKs: yes. Staying current with the compiler and runtime reduces long-term migration pain.

For production services: probably wait for the next LTS unless a specific feature is compelling. Non-LTS releases have only 6 months of support; upgrading every six months is expensive.

For exploration and playgrounds: definitely. Previews become finals; getting familiar early pays off when they ship to LTS.

Migration cost from 25 → 26

Usually low. Most breaking changes happen in the first major release after an LTS, not between non-LTS. Expected issues:

  • Libraries that haven’t certified on 26 yet
  • Security Manager cleanup if you still use it
  • Experimental → default JVM flags (check your tuning)

Closing thought

Java’s release cadence is steady and boring in the best way. Java 26 continues the gradual, high-quality improvements that the language has been shipping since the six-month cadence started. Worth reading the release notes, worth experimenting in POCs. Whether you ship it in production depends on your LTS cadence — but knowing what’s coming in the next LTS helps you plan.