Java’s Multi-Project Evolution: Valhalla, Panama & AmberReach Maturity

2023 to 2026 brought more meaningful change to the Java platform than the entire preceding decade. Here’s the complete picture.

For most of the 2010s, Java’s evolution was largely incremental. You got lambdas and streams in Java 8, modules in Java 9, and then a string of six-month releases that collectively moved the needle — but slowly. The language felt stable to the point of stagnation. Developers who’d been waiting for Java to close the ergonomic gap with Kotlin, Scala, and C# found themselves routinely disappointed.

Then, between 2021 and 2026, something shifted. Three long-running OpenJDK projects — Amber (language expressiveness), Panama (native interop), and Valhalla (value types and performance) — began delivering. Not just early-access previews and experimental builds, but finalized, production-grade features that are changing how Java code looks, performs, and integrates with the outside world.

Java 25, released in September 2025 as the latest LTS, is the clearest evidence that this isn’t incremental anymore. Java 8 usage plummeted to 23% from 40% in 2023, while Java 21 adoption reached 45% according to JRebel’s 2025 Developer Productivity Report — the fastest uptake in Java history. The ecosystem is moving, and the projects are a significant reason why.

Java Version Adoption Share (Production) — 2023 vs 2025

1. Before the Projects: What Was Actually Wrong

The critique of Java before this wave of changes had three distinct dimensions. First, the language was verbose in ways that felt gratuitous — writing a simple data-carrying class required constructors, getters, equals(), hashCode(), and toString(), all boilerplate that communicated nothing about the developer’s intent. Second, native interop was painful — calling a C library through JNI meant writing Java, C headers, and glue code simultaneously, with failure modes that could crash the entire JVM rather than throw a clean exception. Third, Java’s object model was expensive in ways that were increasingly visible on modern hardware: every object carried identity overhead, every primitive had to be “boxed” into a heap-allocated wrapper to participate in generic collections, and the resulting pointer indirection fragmented cache lines that modern CPUs depend on.

Each of the three projects was targeted at one of these problems. The story of Java 2023–2026 is largely the story of those targeted solutions reaching production.

2. Project Amber: Making Java Say What You Mean

Amber’s mandate was always developer productivity — reducing the tax Java’s syntax imposed on expressing ideas clearly. It delivered through a coordinated set of features that, individually, seem like quality-of-life improvements but together represent a genuine shift in how Java code is structured.

Records, finalized in Java 16, are the most immediately visible Amber contribution. A record declaration is a concise statement of intent: this is an immutable data carrier, defined by its components. The compiler generates the constructor, accessors, equals, hashCode, and toString automatically. According to the 2024 BellSoft developer survey, 55% of Java developers are now using records regularly — a remarkable adoption rate for a feature that shipped only four years ago.

Sealed classes, also finalized in Java 17, did something conceptually significant: they brought algebraic data types to Java. By declaring exactly which classes may implement or extend a type, sealed classes enable the compiler to reason about exhaustiveness — a property that pairs directly with pattern matching to eliminate entire categories of bugs.

Pattern matching arrived in stages. The instanceof pattern landed in Java 16. Switch pattern matching completed its journey from Java 17 preview to Java 21 finalization. Record patterns — allowing destructuring directly in pattern matching expressions — finalized alongside it. Together, these features let you write exhaustive type analysis without casting, without null checks, and with compiler-enforced completeness.

// Pattern matching in Java 21+ — run with any JDK 21+ installation

// Sealed interface with three known implementations
sealed interface HttpResult permits Success, NotFound, ServerError {}

record Success(int status, String body)     implements HttpResult {}
record NotFound(String message)              implements HttpResult {}
record ServerError(int code, String reason)  implements HttpResult {}

// Exhaustive switch — compiler rejects missing cases
static String describe(HttpResult result) {
    return switch (result) {
        case Success(var code, var body)  -> "OK (" + code + "): " + body;
        case NotFound(var msg)            -> "404: " + msg;
        case ServerError(var code, var r) -> "Error (" + code + "): " + r;
    };
}

What’s changed is the style of programming this enables. Amber features push Java toward what Brian Goetz, Java’s lead language architect, calls data-oriented programming — treating data as data, with its structure made explicit in types rather than encoded in procedural logic. A February 2026 OpenJDK design note on carrier classes signals that Amber continues to extend this model even after records and sealed classes are fully shipped.

Still in progress: String Templates, which were previewed in Java 21 and 22 before being withdrawn in Java 23, are being redesigned. The original design was deemed insufficient for safe SQL and HTML interpolation. A new proposal is expected to land in a future release with better handling of injection-sensitive contexts.

3. Project Panama: Burying JNI

JNI — the Java Native Interface — has existed since Java 1.1. Developers who have used it describe it as one of the most unpleasant experiences in the Java ecosystem: a fragile bridge of Java declarations, C header files, and native implementations that must be kept in sync manually, deployed across architectures, and maintained as both sides evolve. A mistake on the native side doesn’t throw a Java exception — it crashes the JVM entirely.

Project Panama spent years in incubation and preview, iterating on the Foreign Function & Memory API through JDK 16, 19, 20, and 21. JDK 22 finalized it in March 2024 under JEP 454. It is now a standard production API. The implementation effort compared to JNI has been reduced by roughly 90%, and the FFM API is claimed to be four to five times faster than JNI for equivalent operations.

The API is built around three core abstractions. MemorySegment models a contiguous region of memory — on-heap or off-heap — with a defined lifetime. Arena controls that lifetime, ensuring memory is freed deterministically and that accessing freed memory throws a clean exception rather than a silent JVM crash. SymbolLookup locates native functions by name, and Linker generates the call mechanism from a Java method handle to a C function — all in pure Java, with no C code required from the caller.

// Call C’s strlen() from pure Java — requires JDK 22+ (no flags needed)

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;

public class PanamaDemo {
    public static void main(String[] args) throws Throwable {
        Linker linker = Linker.nativeLinker();

        // Look up strlen in the C standard library
        MethodHandle strlen = linker.downcallHandle(
            linker.defaultLookup().find("strlen").orElseThrow(),
            FunctionDescriptor.of(ValueLayout.JAVA_LONG,
                                   ValueLayout.ADDRESS)
        );

        // Allocate native memory, write a string, measure it
        try (Arena arena = Arena.ofConfined()) {
            MemorySegment str = arena.allocateFrom("Hello from Panama!");
            long len = (long) strlen.invoke(str);
            System.out.println("Length: " + len); // 18
        }
    }
}

For most Java developers, the practical benefit isn’t calling C directly — it’s that the libraries they depend on no longer need JNI under the hood. Machine learning frameworks, cryptography libraries, audio engines, GPU compute interfaces: all of these can now be wrapped in pure Java with the FFM API rather than through fragile JNI bindings. The jextract tool generates Java bindings directly from C header files, making the conversion largely mechanical for most native libraries.

“The FFM API is one of the most significant updates to Java in recent years. Java has finally bridged the gap to the native world — safely, efficiently, and in pure Java.”— HappyCoders.eu, 2025 analysis of JEP 454

Panama also delivered the Vector API — incubating since JDK 16 and still finishing its journey to finalization — which exposes SIMD (Single Instruction, Multiple Data) processor instructions through a portable Java API. For numerical workloads, image processing, or any computation that currently relies on hand-tuned native code to exploit hardware parallelism, the Vector API delivers that capability in portable Java for the first time.

4. Project Valhalla: The Long Game, Finally Moving

Of the three projects, Valhalla has the longest timeline, the deepest implications, and the most unfinished work remaining. It is also, arguably, the most architecturally significant. What Valhalla is attempting is a modification of Java’s fundamental object model — not its syntax, but the way the JVM represents, allocates, and passes objects at the machine level.

The core insight is that Java’s current model treats every object as a heap-allocated, identity-bearing entity. That made sense in 1995, when memory was flat and cache didn’t matter. In 2026, with processors running at 4–5GHz on caches measured in megabytes, pointer indirection is one of the primary sources of CPU stalls. A list of Point objects is stored as an array of pointers, each pointing to a separately allocated object somewhere on the heap. A list of 10,000 points is 10,000 pointer dereferences to access sequentially — terrible for cache locality.

Valhalla’s answer is value classes (JEP 401, currently in preview for JDK 26 via early-access builds). A value class declares that its instances have no identity — equality is purely structural, synchronization is forbidden, and the JVM is free to flatten the fields directly into containing arrays and objects. Early-access benchmarks from inside.java show 35–40% latency improvements on array-intensive workloads, with the performance gap between value types and native primitives narrowing significantly after JIT compilation.

JEP 401 technical constraint to know: Value objects with 64 bits or more of field data cannot currently be heap-flattened atomically. Scalarization (stack allocation) requires C2 JIT compilation, so during the warmup phase, value objects still allocate on the heap. Integer and LocalDate are among the JDK classes designated to become value classes when the feature finalizes — signaling how deeply the change will permeate the standard library.

The five features under active Valhalla development are Value Classes and Objects, Null-restricted and Nullable types, Enhanced Primitive Boxing (enabling List<int>), Reified Generics (retaining type information at runtime), and Array Enhancements. They will not ship all at once. The project page is explicit: these will flow through multiple JDK releases over the coming years. JEP 401 targeting JDK 26 as a preview is the first concrete step in a multi-release delivery.

The long-term payoff is substantial. Generic collections of primitives without boxing, type-specialized generic classes, arrays that store value types inline — these changes will ripple through frameworks, JVM languages, and libraries in ways that will be largely invisible to application developers but deeply felt in performance characteristics. Brian Goetz has suggested that operator overloading could follow value types as a natural next step, since value semantics would make overloaded arithmetic on numeric types meaningful.

5. The Context: Loom and Leyden Complete the Picture

Amber, Panama, and Valhalla don’t exist in isolation. Two other projects are essential context for understanding why 2023–2026 represents such a structural shift.

Project Loom, which delivered virtual threads as a finalized feature in Java 21, solved the concurrency scaling problem that had made Java expensive for highly concurrent applications. Before Loom, each thread mapped to an OS thread — typically 1MB of stack, with tens of thousands being a practical ceiling. Virtual threads are lightweight continuations scheduled by the JVM, costing roughly 200–300 bytes each. Writing a million concurrent tasks in Java 21 is now practical without reactive programming frameworks. The language looks synchronous, the performance is asynchronous. This was the serverless cold-start story of the previous article, but it also matters for any service under high connection load.

Project Leyden, which began delivering AOT (ahead-of-time) startup improvements in JDK 24 and 25, addresses startup time without requiring GraalVM native compilation. JDK 24 achieved 40% faster startup for Spring PetClinic via Leyden’s AOT caching. This is the JVM learning from application behavior at training time and persisting those optimizations — a more portable, lower-friction alternative to fully native images for teams that need better startup but can’t afford GraalVM’s build complexity constraints.

Key Java Features Delivered: 2021 vs 2023–2026

6. The Feature Status Map

Between all these projects, it can be hard to track exactly where each feature sits. This table maps the major project deliverables to their current status as of February 2026.

7. What This Means for Java Developers Today

The most immediate takeaway is practical: if you’re still on Java 11 or 17, you are missing a substantial amount of language capability that has been production-stable for years. Records, sealed classes, pattern matching, and switch pattern matching all require Java 21 to use fully. The Foreign Function and Memory API requires Java 22. The JDK 21 LTS adoption trajectory suggests the ecosystem has recognized this — 45% of developers report using it in production as of 2025.

For teams doing greenfield development, the combination of records, sealed interfaces, and exhaustive pattern matching represents a different way of writing Java. You model your domain as explicit data types — sealed hierarchies of records — and write operations as switch expressions that the compiler guarantees are complete. This is a programming style that Java simply didn’t support three years ago. It’s not a new language, but it asks for a new mental model.

For teams thinking about performance, the answer depends on your timeline. Loom and Leyden are deliverable today — virtual threads for concurrency, AOT caching for startup. Valhalla’s value classes will likely finalize in JDK 27 or 28 (following the current LTS-every-two-years cadence), but teams working on data-intensive code should be watching JEP 401 closely and prototyping on early-access builds now.

8. What We’ve Learned

Java’s evolution between 2023 and 2026 has been genuinely structural, not just cosmetic. Project Amber has delivered a complete set of expressive language features — records, sealed classes, pattern matching, and record patterns — that together enable data-oriented programming idioms Java could not express before. Project Panama finalized the Foreign Function & Memory API in JDK 22, burying JNI with a pure-Java replacement that is 4–5 times faster and requires 90% less implementation effort. Project Loom’s virtual threads (JDK 21) resolved Java’s concurrency scaling problem at the platform level.

Project Valhalla remains the longest arc, with value classes now in early-access preview for JDK 26 under JEP 401. The full delivery — value types, primitive generics, and reified type parameters — will span several more releases, but the first concrete preview is a meaningful milestone. Project Leyden is delivering AOT startup improvements without GraalVM’s complexity, with 40% faster startup demonstrated in JDK 24.

The adoption numbers confirm that the ecosystem is responding. Java 8 usage fell from 40% to 23% in two years, while Java 21 adoption reached 45% — the fastest LTS uptake in Java’s history. The claim that 2023–2026 brought more change than the previous decade isn’t hyperbole. It’s the convergence of multiple long-running projects, each targeting a different dimension of Java’s limitations, delivering their results simultaneously into a community that was ready to adopt them.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

I agree to the Terms and Privacy Policy

Sign up

Thank you!

We will contact you soon.