Testing JDK 25 RC: My Experience & Early Thoughts

There’s a unique thrill in the air when a new Java Development Kit (JDK) enters its Release Candidate (RC) phase. It’s that final stretch before the official General Availability (GA) release, where the platform stabilizes, and we get a solid, feature-complete version to put through its paces. For Java enthusiasts, it’s like unwrapping a gift a little early. The past week, I’ve been doing just that—diving headfirst into the JDK 25 RC, and I’m excited to share my initial findings.

This isn’t just about seeing what’s new on paper; it’s about compiling real code, running existing applications, and getting a feel for how these changes will impact our day-to-day work as developers. The RC phase is crucial. It’s our last chance as a community to kick the tires and report any show-stopping bugs before millions of developers depend on it. My goal was to explore the most significant Java Enhancement Proposals (JEPs), test for any regressions, and gauge the overall maturity of the release.

So, grab your favorite cup of coffee. We’re about to explore the practical side of JDK 25, from the delightful ergonomics of String Templates to the powerful new capabilities of Stream Gatherers and the sanity-restoring Structured Concurrency. Let’s get started.

Getting Started: Setting Up JDK 25 RC

Getting your hands on the JDK 25 RC is refreshingly simple. The OpenJDK project provides ready-to-use builds on the official JDK 25 project page. If you’re a fan of SDKMAN!, the process is even more streamlined. A single command is all it takes:

sdk install java 25-rc-open

Once installed, a quick version check confirms we’re ready to roll:

$ java --version
openjdk 25 2025-09-16
OpenJDK Runtime Environment (build 25+36-2344)
OpenJDK 64-Bit Server VM (build 25+36-2344, mixed mode, sharing)

With the environment set up in less than a minute, I was ready to explore the most anticipated features. I configured my IntelliJ IDEA to use the new JDK, and it correctly identified the language level and preview features, which is always a good sign.

Diving into the JEPs: Hands-On with New Features

JDK 25 continues Java's trajectory of thoughtful evolution, focusing heavily on developer productivity and simplifying complex tasks. This release polishes several preview features, bringing them closer to their final form.

String Templates (JEP 459): Cleaner and Safer

String Templates, now in their second preview, are poised to become the definitive way we compose strings in Java. They offer the readability of string interpolation from other languages without sacrificing Java’s commitment to type safety and security. The default STR template processor is a joy to use.

Let’s look at a simple "before" and "after."

Before (String concatenation or format):

// Clunky and error-prone
String name = "Elena";
int orderId = 12345;
String json = "{\"name\": \"" + name + "\", \"orderId\": " + orderId + "}";

After (Using STR processor):

// Clean, readable, and safe
String name = "Elena";
int orderId = 12345;
String json = STR."{\"name\": \"\{name}\", \"orderId\": \{orderId}}";

The improvement is immediately obvious. The code is far more readable and less prone to concatenation errors. What’s more, the template processor automatically handles proper escaping if the embedded expressions evaluate to strings. In this second preview, I noticed subtle improvements in compiler diagnostics, providing clearer error messages for malformed templates. This feature feels incredibly polished and ready for prime time.

Stream Gatherers (JEP 461): Supercharging Stream Pipelines

The Stream API is one of Java 8's greatest gifts, but it has always had limitations. Certain stateful intermediate operations were difficult, if not impossible, to express elegantly. Stream Gatherers, also in a second preview, aim to fix this. A Gatherer is a new kind of intermediate operation that can transform a stream of elements in powerful ways, including one-to-many, many-to-one, or many-to-many transformations.

Consider an operation where you want to group elements into fixed-size windows. Before, this was a convoluted task. With Gatherers, it’s straightforward.

// Using a built-in Gatherer to create sliding windows of 3
List numbers = List.of(1, 2, 3, 4, 5, 6, 7);
List> windows = numbers.stream()
    .gather(Gatherers.windowSliding(3))
    .toList();

// Output: [[1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5, 6], [5, 6, 7]]

This is just scratching the surface. The API allows for custom gatherers, opening the door to complex stream processing for tasks like data de-duplication, filtering based on previous elements, and more. Testing this feature felt like unlocking a new level in the Stream API. It’s a powerful tool for data-processing pipelines, and the built-in gatherers like windowSliding and windowFixed are excellent additions.

Structured Concurrency (JEP 462): Sanity in the Async World

With Virtual Threads making concurrent programming more accessible, we need better ways to manage the complexity. Unstructured, fire-and-forget concurrency leads to resource leaks, cancellation nightmares, and hard-to-debug code. Structured Concurrency, now in its second preview, provides a robust solution.

The core idea is to treat concurrent tasks as a single unit of work within a lexical scope. If one task fails, the others can be automatically cancelled. The main thread waits for all subtasks to complete before moving on. The StructuredTaskScope class is the entry point.

Imagine fetching a user's data and order history from two different services concurrently:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Supplier user = scope.fork(this::findUser);
    Supplier> orders = scope.fork(this::fetchOrders);

    scope.join(); // Wait for both to complete
    scope.throwIfFailed(); // Propagate exception if any task failed

    // If we get here, both completed successfully
    return new UserProfile(user.get(), orders.get());
}

This code is incredibly clear. The lifetime of the concurrent operations is confined to the try-with-resources block. If fetchOrders() fails, the findUser() task is automatically cancelled. This pattern drastically simplifies error handling and makes concurrent code as easy to reason about as sequential code. This JEP is a monumental step forward for writing reliable, maintainable concurrent applications in Java.

Performance Sneak Peek: An Experimental Flag

Beyond the headline JEPs, I was curious about under-the-hood performance improvements. JDK 25 includes an interesting experimental feature I tested: Compact Object Headers. In the JVM, every object has a header that stores metadata like its hash code and locking information. On a 64-bit JVM, this header is typically 12 bytes. For applications that create millions of small objects, this overhead adds up.

JDK 25 introduces the -XX:+UseCompactObjectHeaders flag, which can reduce this header to just 8 bytes in many cases. I ran a simple microbenchmark creating a large array of simple objects.

The results speak for themselves. While this is an experimental flag and shouldn’t be used in production without extensive testing, it signals a promising direction for reducing Java’s memory footprint, especially in data-intensive applications. It's a testament to the continuous work being done to make the JVM more efficient.

Tooling and Compatibility: Any Surprises?

A new JDK is only as good as its ecosystem support. I’m happy to report that the experience was smooth. Both Maven and Gradle handled the new JDK without issue using their respective toolchain configurations. My existing projects, a mix of Spring Boot and Jakarta EE applications, compiled and ran all unit and integration tests successfully against JDK 25.

IntelliJ IDEA Ultimate 2024.3 (EAP) had excellent support, providing syntax highlighting and inspections for the new preview features right out of the box. This tight integration between the language and tooling is critical for adoption, and it’s great to see the JetBrains team on top of it.

Final Thoughts: Is JDK 25 a Game-Changer?

After a week of intensive testing, my impression of JDK 25 is overwhelmingly positive. It's a release that focuses squarely on refining the developer experience. It doesn't introduce a single, massive, revolutionary feature like Virtual Threads in JDK 21. Instead, it delivers a suite of highly impactful, evolutionary improvements that will make our code cleaner, safer, and easier to reason about.

String Templates and Stream Gatherers are fantastic quality-of-life improvements, while Structured Concurrency is a fundamental advancement for building modern, robust applications. The stability of the RC build gives me confidence that we’re heading for a very solid GA release.

If you haven’t already, I strongly encourage you to download the JDK 25 RC. Run your own projects against it. Play with the new features. The more eyes we have on it now, the better the final release will be for everyone. JDK 25 is shaping up to be another fantastic step forward for the Java platform.