Regardless of any future plans, this post focuses on everything that has been added in this release, giving you a brief introduction to each of the features. Where applicable the differences with Java 25 are highlighted and a few typical use cases are provided, so that you’ll be more than ready to start using these features after reading this.

Photo by Rodolfo Quirós, from Pexels

JEP Overview

To start off, let’s see an overview of the JEPs that ship with Java 26. This table contains their preview status, to which project they belong, what kind of features they add and the things that have changed since Java 25.

New features

Let’s start with the JEPs that add brand-new features to Java 26.

HotSpot

Java 26 introduces two new features in HotSpot:

• JEP 516: Ahead-of-Time Object Caching with Any GC
• JEP 522: G1 GC: Improve Throughput by Reducing Synchronization

The HotSpot JVM is the runtime engine that is developed by Oracle. It translates Java bytecode into machine code for the host operating system’s processor architecture.

JEP 516: Ahead-of-Time Object Caching with Any GC

An important metric for applications that require a fast response time, such as web servers or real-time systems, is tail latency (the time it takes for a request to be processed). It can be caused by either garbage collection pauses, or requests that are sent to a new, not-yet-warmed-up JVM instance. The first cause can be mitigated by using a low-latency garbage collector, such as the Z Garbage Collector (ZGC), while the second can be mitigated by using the ahead-of-time cache, which allows JVM instances to start up faster.

Java 24 introduced this ahead-of-time cache, storing classes in memory after reading, parsing, loading and linking them as a result of an initial training run. Then, it could be re-used in subsequent runs of the application to improve startup time. However, back then the use of the cache was somewhat limited, as cached Java objects were stored in a GC-specific format, making it incompatible with other garbage collectors like ZGC. JEP 516 extends support for the ahead-of-time cache to ZGC (and to any other garbage collector for that matter) by caching Java objects in a GC-agnostic format.

What Makes the New Cache Format GC-Agnostic?

Each garbage collector has its own policies for laying out objects in memory, which means that the memory addresses of cached objects are not valid across different garbage collectors. To solve this problem, JEP 516 changes the cache format by replacing memory addresses with logical indices. When the cache is loaded, these logical indices are converted back to memory addresses by streaming them into memory, materializing the cached objects in the process.

Usage

The JVM will automatically cache objects in the streamable, GC-agnostic format if, in training, either ZGC or the -XX:-UseCompressedOops command-line option was used, or if the heap was larger than 32GB. In contrast, it will cache objects in the old, GC-specific format if, in training, the -XX:+UseCompressedOops (notice the ‘ plus’) command-line option was used. This indicates that the training environment had a heap smaller than 32GB and did not use ZGC.

If you want to force the use of the new GC-agnostic cache format regardless of the training environment, you can specify the -XX:+AOTStreamableObjects command-line option to make it happen.

Why Not Simply Create ZGC-Specific Caches?

The alternative of creating ZGC-specific caches was not pursued because it would have required maintaining separate caches for each garbage collector. Moreover, the only benefit of a ZGC-specific cache would have been a slightly better performance on single-core machines. This benefit would have been negligible in practice, as the highly-concurrent ZGC was designed to perform well on multi-core machines rather than single-core machines, and it would not have justified the maintenance cost of multiple caches.

More Information

For more information on this feature, read JEP 516.

JEP 522: G1 GC: Improve Throughput by Reducing Synchronization

G1 GC has been Java’s default garbage collector since Java 9. It’s been designed to provide high performance and low pause times for applications with large heaps, with the aim of balancing latency and throughput. To achieve this balance, G1 performs its work concurrently with the application, making the application threads share the CPU with GC threads. This situation requires thread synchronization, which unfortunately lowers throughput and increases latency.

JEP 522 proposes to improve both throughput and latency by reducing the amount of synchronization required between application threads and GC threads.

Why Is Synchronization Currently Necessary?

When G1 reclaims memory, live objects in the heap are copied to new memory regions, freeing up the space they leave behind. References to those objects must be updated to point to their new location. To prevent having to scan the entire heap for existing references to these objects, G1 maintains a data structure called the card table, which is updated every time an object reference is stored in a field. These updates are performed by pieces of code called write barriers, which G1 injects into the application in cooperation with the Just-In-Time (JIT) compiler.

Scanning the card table is an efficient operation and will typically fit within a GC pause’s time window. However, in environments where objects are allocated very frequently the card table may grow too large to be scanned within the timespan of G1’s pause time goal. To avoid that, G1 optimizes the card table in the background via separate optimizer threads. This approach can only work if the card table is updated in a thread-safe way, which is currently achieved by synchronizing the optimizer threads with the application threads. Arguably, this leads to more complicated and slower write-barrier code.

Towards A Second Card Table

JEP 522 proposes to introduce a second card table, to make sure the optimizer threads and application threads no longer interfere. The write barriers in the application threads will update the first card table without any synchronization, while the optimizer threads will update the second, initially empty, card table.

When G1 determines that scanning the current card table during a pause would likely breach the pause‑time target, it atomically switches the two card tables. Application threads then continue to write to the now‑empty table (the former “second” table), while dedicated optimizer threads process the previously‑filled table (the former “first” table) without any additional synchronization. G1 repeats this swapping as needed so that the work required on the active card table stays within the desired limits.

This approach reduces the amount of synchronization required between application and optimizer threads. In applications that heavily modify object-reference fields, throughput gains of 5-15% can be expected. On top of that, because the write barrier code can be a lot simpler, additional throughput gains of up to 5% have been observed in x64 architectures, even in applications that don’t heavily modify object-reference fields.

The two card tables are identical in size, each consuming the same extra native memory. Together they occupy roughly 0.2% of the Java heap, which translates to about 2MB of native memory for every gigabyte of heap space. This modest overhead is well worth the sizable performance gains—especially when you consider that, before Java 20, G1 needed more than eight times the memory that the second card table now requires.

More Information

For more information on this feature, read JEP 522.

Core Libs

Java 26 introduces a single new feature that is part of the Core Libs:

• JEP 517: HTTP/3 for the HTTP Client API

JEP 517: HTTP/3 for the HTTP Client API

Since Java 11, a modern HTTP client API is available within the Java Platform. It supports both HTTP/1.1 and HTTP/2 and was designed to potentially support future versions as well. In its current form, the API assumes HTTP/2 by default, but it can revert to HTTP/1.1 should the target server not support a newer HTTP version.

The code example below demonstrates the ease of use and protocol agnosticity of the API:

import java.net.http.*;

...
var client = HttpClient.newHttpClient();
var request = HttpRequest.newBuilder(URI.create("https://hanno.codes")).GET().build();
var response = client.send(request, HttpResponse.BodyHandlers.ofString());
assert response.statusCode() == 200;
String htmlText = response.body();
assert htmlText.contains("Java");

As you can see, we didn’t specify any HTTP version in this code example–the API assumes HTTP/2 by default.

HTTP/3: HTTP’s Next Version

HTTP/3 was standardized in 2022 by the IETF, using the QUIC transport-layer protocol over TCP. Applications that use the HTTP/3 protocol can benefit from multiplexing, faster handshakes, avoidance of network congestion issues and more reliable transport, among others. Most web browsers already support HTTP/3 and about a third of all web sites currently benefit from its features. So this seems like a good time to start supporting it in the HTTP client API, which is exactly what JEP 517 is proposing.

Using HTTP/3 In Java Code

In Java 26, the HTTP client API requires you to opt-in to HTTP/3 by configuring an instance of either HttpClient or HttpRequest with the HTTP_3 version. For example:

// for reuse with multiple requests
var http3Client = HttpClient.newBuilder().version(HttpClient.Version.HTTP_3).build();

// just for a single request
var http3Request = HttpRequest.newBuilder(URI.create("https://hanno.codes"))
    .version(HttpClient.Version.HTTP_3)
    .GET().build();

Once HTTP/3 has been chosen—either in the request itself or in the client—you transmit the request just as you normally would. If the destination server lacks HTTP/3 support, the request is automatically and transparently rolled back to HTTP/2 or, if necessary, to HTTP/1.1.

Negotiating Protocol Versions

The HTTP client API can’t know for sure if a target server will support HTTP/3. Moreover, existing HTTP/1.1 and HTTP/2 connections cannot be upgraded to HTTP/3, since HTTP/1.1 and HTTP/2 are built on top of TCP, while HTTP/3’s QUIC is based on UDP datagrams. So the API needs a way to negotiate protocol versions–in order to do that, it’s been equipped with four separate approaches:

1. Try HTTP/3 first, fall back if it times‑out – Initiate the request with HTTP/3; if a connection cannot be established within a reasonable timeout, automatically downgrade to HTTP/2 or HTTP/1.1. (matches a HttpRequest whose preferred version is set to HTTP_3)

2. Race HTTP/3 against an older protocol – Open both an HTTP/3 connection and an HTTP/2 or HTTP/1.1 connection simultaneously and use whichever succeeds first. (occurs when the HttpClient prefers HTTP_3 but the HttpRequest does not specify a preferred version)

3. Start with HTTP/2 or 1.1 and switch on discovery – Send the initial request over HTTP/2 or HTTP/1.1. If the server’s response indicates that HTTP/3 is available, switch to HTTP/3 for all following requests. (triggered by setting Http3DiscoveryMode.ALT_SVC for the H3_DISCOVERY option, with at least one of the clients or requests preferring HTTP_3)

4. Force HTTP/3 only – Send every request exclusively over HTTP/3; if the server cannot reply with HTTP/3, treat it as a failure and do not fall back to earlier protocols. (enabled by Http3DiscoveryMode.HTTP_3_URI_ONLY for the H3_DISCOVERY option, with at least one client or request preferring HTTP_3)

The four methods each come with their own drawbacks:

• Option 1 incurs a timeout delay before falling back.
• Option 2 may waste resources by establishing an HTTP/3 connection that is never reused.
• Option 3 requires an initial HTTP/2 or HTTP/1.1 round‑trip before any HTTP/3 benefits are realized.
• Option 4 only works when you already know that the target server supports HTTP/3.

HTTP/3 is not as widely deployed as its older counterparts, which is why no single approach can work in all circumstances. This is also the main reason why HTTP/3 can’t be made the default protocol version at this time, though this may be change in the future when HTTP/3 is more widely adopted.

More Information

For more information on this feature, read JEP 517.

Repreviews

Now it’s time to take a look at a few features that might already be familiar to you, because they were introduced in a previous version of Java. They have been repreviewed in Java 26, with only minor changes compared to Java 25 in most cases.

JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)

Within a Java context, cryptographic objects such as public keys, private keys and certificates can be easily created and distributed. But outside of the Java world, the de facto standard is the Privacy-Enhanced Mail (PEM) format. Let’s see an example of a PEM-encoded cryptographic object:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEi/kRGOL7wCPTN4KJ2ppeSt5UYB6u
cPjjuKDtFTXbguOIFDdZ65O/8HTUqS/sVzRF+dg7H3/tkQ/36KdtuADbwQ==
-----END PUBLIC KEY-----

The Java Platform currently doesn’t include an easy-to-use API for decoding and encoding text in the PEM format, which means that decoding a PEM-encoded key can be a tedious job that involves careful parsing of the source PEM text. To further illustrate this point, encrypting and decrypting a private key currently requires over a dozen lines of code.

To solve this problem, JEP 524 introduces an API that can encode objects to the PEM format. It effectively acts as a bridge between Base64 and cryptographic objects. It involves a new interface and three new classes, in the java.security package:

DEREncodable

A sealed interface that groups together all cryptographic objects that support converting their instances to and from byte arrays in the Distinguished Encoding Rules (DER) format.

PEMEncoder

A class that declares methods for encoding DEREncodable objects into PEM text.

PEMDecoder

A class that declares methods for decoding PEM text to DEREncodable objects.

PEM

A record that implements DEREncodable, which can hold any type of PEM data. It allows you to encode and decode PEM tests yielding cryptographic objects for which no Java representation currently exists.

Typical Usage

The following code example shows typical usage of the API:

PrivateKey privateKey = ...;
PublicKey publicKey = ...;

// let's encode a cryptographic object!
PEMEncoder pemEncoder = PEMEncoder.of();

// this returns PEM text in a byte array
byte[] privateKeyPem = pemEncoder.encode(privateKey);

// this returns PEM text in a String
String keyPairPem = pemEncoder.encodeToString(new KeyPair(privateKey, publicKey)); 

// this returns encrypted PEM text
String password = "java-first-java-always";
String pem = pemEncoder.withEncryption(password).encodeToString(privateKey);

// let's decode a cryptographic object!
PEMDecoder pemDecoder = PEMDecoder.of();

// this returns a DEREncodable, so we need to pattern-match
switch (pemDecoder.decode(pem)) {
    case PublicKey publicKey -> ...;
    case PrivateKey privateKey -> ...;
    default -> throw new IllegalArgumentException("Unsupported cryptographic object");
}

// alternatively, if you know the type of the encoded cryptographic object in advance:
PrivateKey key = pemDecoder.decode(pem, PrivateKey.class);

// this decodes an encrypted cryptographic object
PrivateKey decryptedkey = pemDecoder.withDecryption(password).decode(pem, PrivateKey.class);

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

What’s Different From Java 25?

A few minor changes were made to the API compared to Java 25:

• PEMRecord was renamed to PEM, and includes a decode() method that returns decoded Base64 content;
• The PEMEncoder and PEMDecoder classes now support the encryption and decryption of KeyPair and PKCS8EncodedKeySpec objects;
• Finally, a few changes were made to the EncryptedPrivateKeyInfo class:
  • The encryptKey methods are now named encrypt, and they now accept DEREncodable objects rather than PrivateKey objects, enabling the encryption of KeyPair and PKCS8EncodedKeySpec objects.
  • It includes getKeyPair methods that decrypt PKCS#8-encoded text containing a PublicKey.
  • The exceptions thrown by the getKey methods are now aligned with those thrown by the nearby getKeySpec methods.

More Information

For more information on this feature, see JEP 524.

JEP 525: Structured Concurrency (Sixth Preview)

Java’s take on concurrency has always been unstructured, meaning that tasks run independently of each other. There’s no hierarchy, scope, or other structure involved, which means errors or cancellation intent is hard to communicate. To illustrate this, let’s look at a code example that takes place in a restaurant:

These code examples were taken from my conference talk “Java’s Concurrency Journey Continues! Exploring Structured Concurrency and Scoped Values”.

public class MultiWaiterRestaurant implements Restaurant {
    @Override
    public MultiCourseMeal announceMenu() throws ExecutionException, InterruptedException {
        Waiter grover = new Waiter("Grover");
        Waiter zoe = new Waiter("Zoe");
        Waiter rosita = new Waiter("Rosita");

        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            Future<Course> starter = executor.submit(() -> grover.announceCourse(CourseType.STARTER));
            Future<Course> main = executor.submit(() -> zoe.announceCourse(CourseType.MAIN));
            Future<Course> dessert = executor.submit(() -> rosita.announceCourse(CourseType.DESSERT));

            return new MultiCourseMeal(starter.get(), main.get(), dessert.get());
        }
    }
}

Note that the announceCourse(..) method in the Waiter class sometimes fails with an OutOfStockException, because one of the ingredients for the course might not be in stock. This can lead to some problems:

• If zoe.announceCourse(CourseType.MAIN) takes a long time to execute but grover.announceCourse(CourseType.STARTER) fails in the meantime, the announceMenu(..) method will unnecessarily wait for the main course announcement by blocking on main.get(), instead of cancelling it (which would be the sensible thing to do).
• If an exception happens in zoe.announceCourse(CourseType.MAIN), main.get() will throw it, but grover.announceCourse(CourseType.STARTER) will continue to run in its own thread, resulting in thread leakage.
• If the thread executing announceMenu(..) is interrupted, the interruption will not propagate to the subtasks: all threads that run an announceCourse(..) invocation will leak, continuing to run even after announceMenu() has failed.

Ultimately the problem here is that our program is logically structured with task-subtask relationships, but these relationships exist only in the mind of the developer. We might all prefer structured code that reads like a sequential story, but this example simply doesn’t meet that criterion.

In contrast, the execution of single-threaded code always enforces a hierarchy of tasks and subtasks, as shown by the single-threaded version of our restaurant example:

public class SingleWaiterRestaurant implements Restaurant {
    @Override
    public MultiCourseMeal announceMenu() throws OutOfStockException {
        Waiter elmo = new Waiter("Elmo");

        Course starter = elmo.announceCourse(CourseType.STARTER);
        Course main = elmo.announceCourse(CourseType.MAIN);
        Course dessert = elmo.announceCourse(CourseType.DESSERT);

        return new MultiCourseMeal(starter, main, dessert);
    }
}

Here, we don’t have any of the problems we had before. Our waiter Elmo will announce the courses in exactly the right order, and if one subtask fails the remaining one(s) won’t even be started. And because all work runs in the same thread, there is no risk of thread leakage.

It became apparent from these examples that concurrent programming would be a lot easier and more intuitive if enforcing the hierarchy of tasks and subtasks was possible, just like with single-threaded code.

Introducing Structured Concurrency

In a structured concurrency approach, threads have a clear hierarchy, their own scope, and clear entry and exit points. Structured concurrency arranges threads hierarchically, akin to function calls, forming a tree with parent-child relationships. Execution scopes persist until all child threads complete, matching code structure.

Shutdown on Failure

Let’s look at a structured, concurrent version of our example now:

public class StructuredConcurrencyRestaurant implements Restaurant {
    @Override
    public MultiCourseMeal announceMenu() throws ExecutionException, InterruptedException {
        Waiter grover = new Waiter("Grover");
        Waiter zoe = new Waiter("Zoe");
        Waiter rosita = new Waiter("Rosita");

        try (var scope = StructuredTaskScope.open()) {
            Supplier<Course> starter = scope.fork(() -> grover.announceCourse(CourseType.STARTER));
            Supplier<Course> main = scope.fork(() -> zoe.announceCourse(CourseType.MAIN));
            Supplier<Course> dessert = scope.fork(() -> rosita.announceCourse(CourseType.DESSERT));

            scope.join(); // 1

            return new MultiCourseMeal(starter.get(), main.get(), dessert.get()); // 2
        }
    }
}

The scope’s purpose is to keep the threads together. At 1, we wait (join) until all threads are done with their work. If one of the threads is interrupted, an InterruptedException is thrown. A RuntimeException can also be thrown here, if an exception occurs in one of the spawned threads. Once we reach 2, we can be sure everything has gone well, and we can retrieve and process the results.

Actually, the main difference with the code we had before is the fact that we create threads (fork) within a new scope. Now we can be certain that the lifetimes of the three threads are confined to this scope, which coincides with the body of the try-with-resources statement.

Furthermore, we’ve gained short-circuiting behaviour. When one of the announceCourse(..) subtasks fails, the others are canceled if they didn’t complete yet. We’ve also gained cancellation propagation. When the thread that runs announceMenu() is interrupted before or during the call to scope.join(), all subtasks are cancelled automatically when the thread exits the scope.

Shutdown on Success

The factory method that gave us the scope (StructuredTaskScope.open()) implements a shutdown-on-failure policy by default, which cancels any remaining tasks in the scope if one of the tasks has failed. A shutdown-on-success policy is also available: it cancels any remaining tasks in the scope if one of the tasks has succeeded. It can be used to avoid doing unnecessary work when a successful result has already been achieved.

We can use a shutdown-on-success policy by calling an overload of the StructuredTaskScope.open() method that takes a Joiner as its parameter. Let’s see what that would look like:

record DrinkOrder(Guest guest, Drink drink) {}

public class StructuredConcurrencyBar implements Bar {
    @Override
    public DrinkOrder determineDrinkOrder(Guest guest) throws InterruptedException, ExecutionException {
        Waiter zoe = new Waiter("Zoe");
        Waiter elmo = new Waiter("Elmo");

        try (var scope = StructuredTaskScope.open(Joiner.<DrinkOrder>anySuccessfulOrThrow())) {
            scope.fork(() -> zoe.getDrinkOrder(guest, BEER, WINE, JUICE));
            scope.fork(() -> elmo.getDrinkOrder(guest, COFFEE, TEA, COCKTAIL, DISTILLED));

            return scope.join(); // 1
        }
    }
}

In this example the waiter is responsible for getting a valid DrinkOrder object based on guest preference and the drinks supply at the bar. In the method Waiter.getDrinkOrder(Guest guest, DrinkCategory... categories), the waiter starts to list all available drinks in the drink categories that were passed to the method. Once a guest hears something they like, they respond and the waiter creates a drink order. When this happens, the getDrinkOrder(..) method returns a DrinkOrder object and the scope will shut down. This means that any unfinished subtasks (such as the one in which Elmo is still listing different kinds of tea) will be cancelled. The join() method at 1 will either return a valid DrinkOrder object, or throw a RuntimeException if one of the subtasks has failed.

More Shutdown Policies

We’ve seen examples of two shutdown policies so far, but four more are provided out-of-the-box through the static factory methods in the StructuredTaskScope.Joiner interface. For example, Joiner.allSuccessfulOrThrow() will keep the scope alive until all subtasks have completed successfully, and cancels it if any subtasks fails. And Joiner.awaitAll() will wait for all subtasks to complete, whether they complete successfully or not. It’s also possible to create your own shutdown policies by implementing the Joiner interface. That will allow you to have full control over when the scope will be shut down and what results will be collected.

What’s Different From Java 25?

A few minor changes were made to the API compared to Java 25:

• A new method in the Joiner interface, onTimeout(), allows implementations of that interface to return a result when a timeout expires.
• Joiner::allSuccessfulOrThrow() now returns a list of results instead of a stream of subtasks.
• Joiner::anySuccessfulResultOrThrow() was renamed to the slightly simpler anySuccessfulOrThrow().
• The static open method that used to take a Joiner and a Function to modify the default configuration now takes a Joiner and a UnaryOperator.

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

JEP 525 has more details on the current state of this feature, should you wish to learn more.

JEP 526: Lazy Constants (Second Preview)

Immutable objects are a far less complicated concept than mutable objects, because they can only be in a single state and can be shared freely across multiple threads. Currently, the main tool to achieve immutability in Java is final fields. But they come with two drawbacks, restricting their potential in many real-world applications:

• they must be set eagerly;
• the order in which multiple final fields are initialized can never be changed, as it is determined by the textual order in which the fields are declared.

Consider the use of immutability in the following code example, which takes place in a guitar store domain:

class OrderController {
    private final Logger logger = Logger.create(OrderController.class);

    void submitOrder(User user, List<Guitar> guitar) {
        logger.info("Ordering new guitars...");
        
        // ...
        
        logger.info("New guitars have been ordered, let's get to work!");
    }
}

Whenever an instance of OrderController is created, the logger field is initialized eagerly, which potentially makes creating an OrderController slow. And this might not be the only place in our application where a logger field is initialized eagerly:

class GuitarStore {
    static final OrderController ORDERS = new OrderController();
    static final GuitarRepository GUITARS = new GuitarRepository();
    static final ManufacturerService MANUFACTURERS = new ManufacturerService();
}

All this initialization work causes the application to start up more slowly, and the worst thing is: it may not even be necessary! If a user is simply browsing the guitar store, with no intention of ordering a new guitar, the OrderController won’t even be called and we will have initialized the logger field for nothing.

Sacrificing Immutability For More Flexible Initialization

The only alternative we currently have is to resort to a mutability-based approach, in which we delay the initialization of complex objects to as late a time as possible:

class OrderController {
    private Logger logger;

    Logger getLogger() {
        if (logger == null) {
            logger = Logger.create(OrderController.class);
        }
        return logger;
    }

    void submitOrder(User user, List<Guitar> guitar) {
        getLogger().info("Ordering new guitars...");
        
        // ...
        
        getLogger().info("New guitars have been ordered, let's get to work!");
    }
}

This improves application startup, but comes with a few drawbacks of its own:

• All accesses to the logger field must go through the getLogger method, but code that fails to follow this practice runs the risk of encountering NullPointerExceptions;
• In multi-threaded environments, multiple logger objects could be created during concurrent calls to the submitOrder method;
• Constant-folding access to an already-initialized logger field is no longer viable, as the JVM can’t trust its content never to change after its initial update.

What we need is a solution that has the best of both worlds:

• a way to promise that a field will be initialized by the time it is used;
• with a value that is computed at most once, and;
• safely with respect to concurrency.

In other words, we want to defer immutability, and have first-class support for it in the Java runtime.

Lazy Constants

JEP 526 introduces that first-class support in the form of lazy constants. A lazy constant is an object of type LazyConstant, that holds a single data value. It must be initialized some time before its content is first retrieved, and is immutable thereafter.

Let’s rewrite the OrderController class to use a lazy constant for its logger:

class OrderController {
    private final LazyConstant<Logger> logger = LazyConstant.of(() -> Logger.create(OrderController.class));

    void submitOrder(User user, List<Guitar> guitar) {
        logger.get().info("Ordering new guitars...");
        
        // ...
        
        logger.get().info("New guitars have been ordered, let's get to work!");
    }
}

Initially, the lazy constant is uninitialized. When it is accessed for the first time through the get() method, it is initialized by invoking the lambda expression that was passed to the of() factory method. If the lazy constant was already initialized, then the get method simply returns its content. Thus, the get method guarantees that the provided lambda expression is evaluated only once (even when it is invoked concurrently).

If we look at the properties of lazy constants, we see that they fill a gap between final and non-final fields:

Usage of lazy constants is certainly not limited to loggers–we can also use a lazy constant to store the OrderController component itself, and related components:

class GuitarStore {
    static final LazyConstant<OrderController> ORDERS = LazyConstant.of(OrderController::new);
    static final LazyConstant<GuitarRepository> GUITARS = LazyConstant.of(GuitarRepository::new);
    static final LazyConstant<ManufacturerService> MANUFACTURERS = LazyConstant.of(ManufacturerService::new);

    public static OrderController orders() {
        return ORDERS.get();
    }

    public static GuitarRepository guitars() {
        return GUITARS.get();
    }

    public static ManufacturerService manufacturers() {
        return MANUFACTURERS.get();
    }
}

The application’s startup time improves because it no longer initializes its components, such as OrderController, up front. Rather, it initializes each component on demand, via the get method of the corresponding lazy constant. Each component, moreover, initializes its sub-components, such as its logger, on demand in the same way.

Under the hood, the JVM will treat the content of any lazy constant that is declared as final as a constant, allowing constant-folding optimizations to happen.

Lazy Lists

What if you wanted to keep track of multiple lazy constants, for example when keeping a pool of objects? We can achieve this by using a lazy list:

class GuitarStore {
    static final int POOL_SIZE = 10;
    static final List<OrderController> ORDERS = List.ofLazy(POOL_SIZE, _ -> new OrderController());

    public static OrderController orders() {
        long index = Thread.currentThread().threadId() % POOL_SIZE;
        return ORDERS.get((int) index);
    }
}

Here, ORDERS is no longer a lazy constant, but a lazy list, in which each element is stored in a lazy constant. To access the content, clients call ORDERS.get(...), passing it an index, of which the first invocation will invoke the lambda function that ignores the index and invokes the OrderController() constructor. Subsequent invocations of ORDERS.get(...) with the same index will return the element’s content immediately.

Lazy Maps

Alternatively, we could have solved the problem with a lazy map, whose keys are known at construction time and whose values are stored in lazy constants, initialized on demand by a computing function that is also provided at construction:

class GuitarStore {
    static final Map<String, OrderController> ORDERS = Map.ofLazy(Set.of("Customers", "Internal", "Testing"), _ -> new OrderController());

    public static OrderController orders() {
        return ORDERS.get(Thread.currentThread().getName());
    }
}

In this example, OrderController instances are associated with thread names (“Customers”, “Internal”, and “Testing” in this case) rather than integer indexes computed from thread identifiers. Lazy maps allow for more expressive access idioms than lazy lists, but otherwise have all the same benefits.

What’s Different From Java 25?

The feature that used to be known as ‘stable values’ was renamed to ‘lazy constants’ to better capture its intended high-level use case.

Other changes have a similar purpose–they include:

• Removing the low-level methods orElseSet, setOrThrow, and trySet, leaving only factory methods that take value-computing functions;
• Moving the factory methods for lazy lists (StableValue.list) and maps (StableValue.map) into the List and Map interfaces, respectively, to enhance discoverability;
• Incorporating the ideas behind ‘stable suppliers’ into the new LazyConstant.get() method;
• Removing the function and intFunction factory methods to further simplify the API;
• Disallowing null as a computed value in order to improve performance and better align lazy constants with constructs such as unmodifiable collections and scoped values.

More Information

JEP 526 has more details on the current state of this feature, should you wish to learn more.

JEP 529: Vector API (Eleventh Incubator)

The Vector API makes it possible to express vector computations that reliably compile at runtime to optimal vector instructions. This means that these computations will significantly outperform equivalent scalar computations on the supported CPU architectures (x64 and AArch64).

Vector Computations? Help Me Out Here!

A vector computation is a mathematical operation on one or more one-dimensional matrices of an arbitrary length. Think of a vector as an array with a dynamic length. Furthermore, the elements in the vector can be accessed in constant time via indices, just like with an array.

In the past, Java programmers could only program such computations at the assembly-code level. But now that modern CPUs support advanced SIMD features (Single Instruction, Multiple Data), it becomes more important to take advantage of the performance gains that SIMD instructions and multiple lanes operating in parallel can bring. The Vector API brings that possibility closer to the Java programmer.

Code Example

Here is a code example (taken from the JEP) that compares a simple scalar computation over elements of arrays with its equivalent using the Vector API:

void scalarComputation(float[] a, float[] b, float[] c) {
   for (int i = 0; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
   }
}

static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;

void vectorComputation(float[] a, float[] b, float[] c) {
    int i = 0;
    int upperBound = SPECIES.loopBound(a.length);
    for (; i < upperBound; i += SPECIES.length()) {
        // FloatVector va, vb, vc;
        var va = FloatVector.fromArray(SPECIES, a, i);
        var vb = FloatVector.fromArray(SPECIES, b, i);
        var vc = va.mul(va)
                   .add(vb.mul(vb))
                   .neg();
        vc.intoArray(c, i);
    }
    for (; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
    }
}

From the perspective of the Java developer, this is just another way of expressing scalar computations. It might come across as being more verbose, but on the other hand it can bring spectacular performance gains.

Typical Use Cases

The Vector API provides a way to write complex vector algorithms in Java that perform extremely well, such as vectorized hashCode implementations or specialized array comparisons. Numerous domains can benefit from this, including machine learning, linear algebra, encryption, text processing, finance, and code within the JDK itself.

What’s Different From Java 25?

Compared to the tenth incubator version of this feature in Java 25, nothing was changed or added.

The Vector API will keep incubating until necessary features of Project Valhalla become available as preview features. When that happens, the Vector API will be adapted to use them, and it will be promoted from incubation to preview.

More Information

For more information on this feature, read JEP 529.

JEP 530: Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

Since Java 23, pattern matching supports primitive types in all pattern contexts, and in the instanceof and switch constructs. The feature has been in three consecutive preview statuses, and will be previewed for a fourth time in Java 26. Let’s first go through the differences with Java 22 before we highlight the changes in the fourth preview.

Pattern Matching for Switch

Java 22’s version of pattern matching for switch didn’t support type patterns that specify a primitive type. In Java 23 support was added for primitive type patterns in switch, allowing the following code example:

switch (reverb.roomSize()) {
    case 1 -> "Toilet";
    case 2 -> "Bedroom";
    case 30 -> "Classroom";
    default -> "Unsupported value: " + reverb.roomSize();
}

…to be written as follows:

switch (reverb.roomSize()) {
    case 1 -> "Toilet";
    case 2 -> "Bedroom";
    case 30 -> "Classroom";
    case int i -> "Unsupported int value: " + i;
}

This also allows guards to inspect the matched value, like so:

switch (reverb.roomSize()) {
    case 1 -> "Toilet";
    case 2 -> "Bedroom";
    case 30 -> "Classroom";
    case int i when i > 100 && i < 1000 -> "Cinema";
    case int i when i > 5000 -> "Stadium";
    case int i -> "Unsupported int value: " + i;
}

Record Patterns

Record patterns used to have limited support for primitive types. Recall that a record pattern decomposes a record into its individual components, but when one of them is a primitive type, the record pattern must be precise about its type. To illustrate this point, consider the following code example:

record Tuner(double pitchInHz) implements Effect {}

var tuner = new Tuner(440); // int argument is widened to double

// Attempt 1: record pattern match on int argument
if (tuner instanceof Tuner(int p)) {} // doesn't compile!

// Attempt 2: record pattern match on double argument
if (tuner instanceof Tuner(double p)) {
    int pitch = p; // doesn't compile! needs a cast to int
}

// Attempt 3: record pattern match on double argument, cast to int
if (tuner instanceof Tuner(double p)) {
    int pitch = (int) p;
}

To put it differently, the Java compiler widens the provided int to a double, but it doesn’t narrow it back to an int. This limitation exists because narrowing could lead to data loss: the value of the double at runtime might exceed the range of an int or have more precision than an int can accommodate. However, one significant advantage of pattern matching is its ability to automatically reject invalid values by not matching them at all. If the double component of a Tuner is either too large or too precise to safely convert back to an int, then instanceof Tuner(int p) would simply return false, allowing the program to manage the large double component in a different code branch.

This is analogous to how pattern matching currently behaves for reference type patterns. For example:

record SingleEffect(Effect effect) {}
var singleEffect = new SingleEffect(...);

if (singleEffect instanceof SingleEffect(Delay d)) {
    // ...
} else if (singleEffect instanceof SingleEffect(Reverb r)) {
    // ...
} else {
    // ...
}

instanceof can be used here to try to match a SingleEffect with a Delay or a Reverb component; it automatically narrows if the pattern matches.

To summarize, the JEP proposes to make primitive type patterns work as smoothly as reference type patterns, allowing Tuner(int p) even if the corresponding record component is a numeric primitive type other than int.

Pattern Matching for instanceof

The Java 22-version of pattern matching for instanceof didn’t support primitive type patterns, but this capability would perfectly align with the purpose of instanceof: to test whether a value can be converted safely to a given type. To convert primitives safely, Java developers had to deal with lossy casts and range checks to prevent loss of information:

int roomSize = reverb.roomSize();

if (roomSize >= -128 && roomSize < 127) {
    byte r = (byte) roomSize;
    // now it's safe to use r
}

The JEP proposes the possibility to replace these constructs with simple instanceof checks that operate on primitives. Let’s rewrite the code example to make use of this feature:

int roomSize = reverb.roomSize();

if (roomSize instanceof byte r) {
    // now it's safe to use r
}

The pattern roomSize instanceof byte r will match only if roomSize fits into a byte, eliminating the need for casts and range checks.

Primitive Types in instanceof

The instanceof keyword used to take a reference type only, and since Java 16 it can also take a type pattern. But it would make sense to have instanceof take a primitive type also. In that case instanceof would check if the conversion is safe but would not actually perform it:

if (roomSize instanceof byte) { // check if value of roomSize fits in a byte
    ... (byte) roomSize ... // yes, it fits! but cast is required
}

The JEP proposes to support this construct, which makes it easier to change the instanceof check to take a type pattern and vice versa.

Primitive Types in switch

The Java 22-version of the switch statement/expression supported byte, short, char, and int values. The JEP proposes to also add support for the other primitive types: boolean, float, double and long. A switch on a boolean value can be a good alternative for the ternary operator (?:), because its branches can also hold statements instead of just expressions.

String guitaristResponse = switch (guitar.isInTune()) {
    case true -> "Ready to play a song.";
    case false -> {
        log.warn("Guitar is out of tune!");
        yield "Let's take five!";
    }
}

What’s Different From Java 25?

One minor change was made compared to Java 25: tighter dominance checks in switch constructs were applied. One pattern is said to dominate another pattern if it matches all the values that the other pattern matches. The definition of dominance used to be applicable to reference types only; this JEP broadens that definition so that primitive types are included as well. As a result, e.g., the type pattern long q is now said to dominate the type pattern int i.

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, read JEP 530.

Deprecations

Java 26 also deprecates a few older features. Let’s see which ones were involved in this effort to improve stability and clarity.

JEP 500: Prepare to Make Final Mean Final

Final fields in Java represent immutable state. Once assigned in a constructor or in a class initializer, a final field cannot be reassigned. This behaviour is important when reasoning about correctness, and for performance reasons. The more constraints there are on the behaviour of a class, the more optimizations the JVM can apply (like constant folding). Moreover, the immutability we can expect from final fields plays an important role in the safe initialization of objects in multi-threaded code.

Unfortunately, the expectation that a final field cannot be reassigned is false. Several APIs allow final fields to be reassigned at any time by any code in a program, undermining all reasoning about correctness and invalidating important optimizations. The deep reflection API is the most notorious of them, through its Field.setAccessible and Field.set methods. These methods allow you to mutate final fields at will, for example:

// A normal class with a final field
static class Guitar {
    final int numberOfStrings;

    Guitar() {
        numberOfStrings = 6;
    }
}

void main() throws ReflectiveOperationException {
    // 1. Perform deep reflection over the final field in Guitar
    java.lang.reflect.Field numberOfStrings = Guitar.class.getDeclaredField("numberOfStrings");
    numberOfStrings.setAccessible(true);      // Make Guitar's final field mutable

    // 2. Create an instance of Guitar
    Guitar guitar = new Guitar();
    IO.println(guitar.numberOfStrings);  // Prints 6

    // 3. Mutate the final field in the object
    numberOfStrings.set(guitar, 12);
    IO.println(guitar.numberOfStrings);  // Prints 12
    numberOfStrings.set(guitar, 4);
    IO.println(guitar.numberOfStrings);  // Prints 4
}

This example shows that, in practice, final fields can be as mutable as non-final fields.

Reasons For Mutating a Final Field

So why was the possibility added in the first place? The answer has to do with (you guessed it!) serialization. Serialization libraries need the ability to mutate final fields when initializing objects during deserialization. The problem is that relative little code mutates final fields for the right reasons, yet the mere existence of APIs for doing so makes it impossible to trust the value of any final field. Looking back, offering this functionality was a poor choice because it sacrifices integrity.

Recent additions like hidden classes and records don’t allow mutating final fields, and now it’s time to extend this behaviour to regular classes.

Final Field Restrictions

JEP 500 proposes to issue warnings when deep reflection is used to mutate final fields. These warnings will prepare developers for a future release that ensures integrity by default by restricting final field mutation, making Java programs safer and potentially faster. One exception to this rule will remain supported, namely serialization libraries that need to mutate final fields during deserialization, via a limited-purpose API.

The effects of these final field restrictions will be strengthened over time. Rather than issue warnings, a future JDK release will, by default, throw exceptions when Java code uses deep reflection to mutate final fields.

Enabling Final Field Mutation

Application developers can avoid these warnings and expections by opting-in to final field mutation via the command-line. To achieve this, specify the --enable-final-field-mutation command-line option and pass it a comma-separated list of module names:

$ java --enable-final-field-mutation=module1,module2

Additional techniques are also available, such as setting environment variables, adding it to a JAR’s manifest or configuring it in a custom runtime using jlink. Refer to JEP 500 for more details on these techniques.

Behaviour of Field::set

In JDK 26 the rules for Field::set on a final field change. The field will be mutated only if:

1. f.setAccessible(true) has already succeeded,
2. the field’s declaring class is in a package open to the caller’s module, and
3. final‑field mutation is enabled for that module.

The last two conditions are new. Consequently:

• If a module doesn’t have final‑field mutation enabled, any attempt to change a final field via deep reflection throws an IllegalAccessException (unless the JVM is started with --illegal-final-field-mutation). f.setAccessible(true) may still succeed, but f.set(...) is illegal.

• If final‑field mutation is enabled but the field’s package isn’t open to the module, the same exception is thrown. This can happen when module A (with an open package) calls f.setAccessible(true) and passes the Field to module B, which has mutation enabled but no access to the package; module B’s f.set(...) is illegal.

Effects On Serialization Libraries

When future JDK releases tighten final‑field restrictions, serialization libraries won’t be able to rely on deep reflection automatically. Instead of asking users to turn on final‑field mutation via command‑line flags, library maintainers should use the sun.reflect.ReflectionFactory API, which is intended for this purpose. This API lets a serialization library acquire a method handle to special JDK‑generated code that can initialize an object by directly writing to its instance fields, even if they’re declared final. The generated code gives the library the same capabilities as the JDK’s built‑in serialization mechanisms, eliminating the need to enable final‑field mutation for the library’s module.

Note that sun.reflect.ReflectionFactory only works for deserializing classes that implement java.io.Serializable.

Libraries and Frameworks Should Not Use Deep Reflection to Mutate Final Fields

Some dependency‑injection, testing, and mocking libraries rely on deep reflection to tamper with objects, even changing final fields. Their maintainers should treat enabling final‑field mutation via command‑line switches as a fallback only. Preferably, they should adopt designs that eliminate the need to alter final or private fields. For instance, most DI frameworks prohibit injecting final fields already and encourage constructor injection instead.

More Information

For more information on this feature, read JEP 500.

JEP 504: Remove the Applet API

When the Java Platform rose to fame in the late 1990s and early 2000s, one of its main catalysts were Java applets and the Applet API. Java applets were small Java programs that could be embedded in web pages and run in a web browser, allowing developers to create interactive web applications. They were widely used for things like games, animations, and other interactive content on the web. People who weren’t Java programmers at all at least knew the name ‘Java’ from their browser because of applets! (in roughly the same way as kids these days know about Java’s existence because of a game called Minecraft.)

However, over time, Java applets became less popular due to security concerns and the rise of alternative technologies such as JavaScript and HTML5. As a result, many browser vendors have removed support for them. This is why the Applet API was deprecated in Java 9, deprecated for removal in Java 17 and it’s one of the reasons why it will be removed in its entirety in Java 26. On top of that, a necessary foundation for running applets by sandboxing untrusted code, the Security Manager, was permanently disabled in Java 24, providing another reason to finally sunset the Applet API.

Removals

The following elements will be removed:

• The entire java.applet package, consisting of:
  • java.applet.Applet
  • java.applet.AppletContext
  • java.applet.AppletStub
  • java.applet.AudioClip
• These additional classes:
  • java.beans.AppletInitializer
  • javax.swing.JApplet
• Any remaining API elements that reference the above classes and interfaces, including methods and fields in:
  • java.beans.Beans
  • javax.swing.RepaintManager

Risks & Migration

Given that the Applet API in its current form is largely unusable, there is no substantial risk to user applications in removing the API. Applications that still use the Applet API will either stay on older releases or will migrate to some other API, like the AWT API or the javax.sound.SoundClip class for audio playback.

More Information

For more information on this removal, read JEP 504.

Final thoughts

And that concludes our discussion of the 10 JEPs that come with Java 26. But that’s not even all that’s new: many other updates were included in this release, including various performance, stability and security updates. One thing is for sure: this version of Java is primed and ready for more additions later this year. So what are you waiting for? It’s time to take this brand-new Java release for a spin!

This post takes you on a tour of everything that is part of this release, giving you a brief introduction to each of them. Where applicable the differences with Java 24 are highlighted and a few typical use cases are provided, so that you’ll be more than ready to start using these features after reading this.

Photo from PxHere

Short descriptions of the repreviewed and finalized features are provided to prevent this article from becoming too lengthy. Each of these features comes with a link to a longer description should you wish to learn more.

JEP Overview

To start off, let’s look at an overview of the JEPs that ship with Java 25. This table contains the preview status for all JEP’s, to which project they belong, what kind of features they add and the things that have changed since Java 24.

New features

Let’s start with the JEP’s that add brand-new features to Java 25.

Core Libs

Java 25 contains a single new feature that is part of the Core Libs:

• Stable Values (Preview)

JEP 502: Stable Values (Preview)

Immutable objects are a far less complicated concept than mutable objects, because they can only be in a single state and can be shared freely across multiple threads. Currently, the main tool to achieve immutability in Java is final fields. But they come with two drawbacks, restricting their potential in many real-world applications:

• they must be set eagerly;
• the order in which multiple final fields are initialized can never be changed, as it is determined by the textual order in which the fields are declared.

Consider the use of immutability in the following code example, which takes place in a guitar store domain:

class OrderController {
    private final Logger logger = Logger.create(OrderController.class);

    void submitOrder(User user, List<Guitar> guitar) {
        logger.info("Ordering new guitars...");
        
        // ...
        
        logger.info("New guitars have been ordered, let's get to work!");
    }
}

Whenever an instance of OrderController is created, the logger field is initialized eagerly, which potentially makes creating an OrderController slow. And this might not be the only place in our guitar store application where a logger field is being initialized eagerly:

class GuitarStore {
    static final OrderController ORDERS = new OrderController();
    static final GuitarRepository GUITARS = new GuitarRepository();
    static final ManufacturerService MANUFACTURERS = new ManufacturerService();
}

All this initialization work causes the application to start up more slowly, and the worst thing is: it may not even be necessary! If a user is simply browsing the guitar store, with no intention of ordering a new guitar, the OrderController won’t even be called and we will have initialized the logger field for nothing.

Sacrificing Immutability For More Flexible Initialization

The only alternative we currently have is to resort to a mutability-based approach, in which we delay the initialization of complex objects to as late a time as possible:

class OrderController {
    private Logger logger;

    Logger getLogger() {
        if (logger == null) {
            logger = Logger.create(OrderController.class);
        }
        return logger;
    }

    void submitOrder(User user, List<Guitar> guitar) {
        getLogger().info("Ordering new guitars...");
        
        // ...
        
        getLogger().info("New guitars have been ordered, let's get to work!");
    }
}

This improves application startup, but comes with a few drawbacks of its own:

• All accesses to the logger field must go through the getLogger method, but code that fails to follow this practice runs the risk of encountering NullPointerExceptions;
• In multi-threaded environments, multiple logger objects could be created during concurrent calls to the submitOrder method;
• Constant-folding access to an already-initialized logger field is no longer viable, as the JVM can’t trust its content never to change after its initial update.

What we need is a solution that has the best of both worlds:

• a way to promise that a field will be initialized by the time it is used,
• with a value that is computed at most once, and
• safely with respect to concurrency.

In other world, we want to defer immutability, and first-class support for it in the Java runtime.

Stable Values

JEP 502 introduces that first-class support in the form of stable values. A stable value is an object of type StableValue, that holds a single data value. It must be initialized some time before its content is first retrieved, and it is immutable thereafter.

Let’s rewrite the OrderController class to use a stable value for its logger:

class OrderController {
    private final StableValue<Logger> logger = StableValue.of();

    Logger getLogger() {
        return logger.orElseSet(() -> Logger.create(OrderController.class));
    }

    void submitOrder(User user, List<Guitar> guitar) {
        getLogger().info("Ordering new guitars...");
        
        // ...
        
        getLogger().info("New guitars have been ordered, let's get to work!");
    }
}

After the call to StableValue.of(), the stable value holds no content. When it is accessed through the getLogger() method, logger.orElseSet(...) returns its content if the stable value was already set. If it is unset, the orElseSet method initializes it with the value supplied by the lambda expression. The orElseSet method also guarantees that the provided lambda expression is evaluated only once, even when it is invoked concurrently.

If we look at the properties of stable values, we see that they fill a gap between final and non-final fields:

Usage of stable values is certainly not limited to loggers–we can also use a stable value to store the OrderController component itself, and related components:

class GuitarStore {
    static final StableValue<OrderController> ORDERS = StableValue.of();
    static final StableValue<GuitarRepository> GUITARS = StableValue.of();
    static final StableValue<ManufacturerService> MANUFACTURERS = StableValue.of();

    public static OrderController orders() {
        return ORDERS.orElseSet(OrderController::new);
    }

    public static GuitarRepository guitars() {
        return GUITARS.orElseSet(GuitarRepository::new);
    }

    public static ManufacturerService manufacturers() {
        return MANUFACTURERS.orElseSet(ManufacturerService::new);
    }
}

The application’s startup time improves because it no longer initializes its components, such as OrderController, up front. Rather, it initializes each component on demand, via the orElseSet method of the corresponding stable value. Each component, moreover, initializes its sub-components, such as its logger, on demand in the same way.

Under the hood, the JVM will treat the content of any stable value that is declared as final as a constant, allowing constant-folding optimizations to happen.

Stable Suppliers

There’s one catch with our current approach: all access to the logger stable value must go through the getLogger method. It would be more convenient if we could separate initializing a stable value from the actual initialization itself. To this end, JEP 502 introduces stable suppliers, and this is how they work:

class OrderController {
    private final Supplier<Logger> logger = StableValue.supplier(() -> Logger.create(OrderController.class));

    void submitOrder(User user, List<Guitar> guitar) {
        logger.get().info("Ordering new guitars...");
        
        // ...
        
        logger.get().info("New guitars have been ordered, let's get to work!");
    }
}

Here, logger is no longer a stable value, but a stable Supplier. When a stable supplier is first created via StableValue.supplier(...), the content of the underlying stable value is not yet initialized. To access the logger, clients call logger.get(), of which the first invocation will invoke the supplier and use its result to initialize the stable value. Subsequent invocations of logger.get() will return the content immediately. The resulting code is arguably more readable, because we no longer need a separate getLogger method.

Stable Lists

What if you wanted to keep track of multiple stable values, for example when keeping a pool of objects? We can achieve this by using a stable list:

class GuitarStore {
    static final int POOL_SIZE = 10;
    static final List<OrderController> ORDERS = StableValue.list(POOL_SIZE, _ -> new OrderController());

    public static OrderController orders() {
        long index = Thread.currentThread().threadId() % POOL_SIZE;
        return ORDERS.get((int) index);
    }
}

Here, ORDERS is no longer a stable value, but a stable list, where each element is the content of an underlying stable value. To access the content, clients call ORDERS.get(...), passing it an index, of which the first invocation will invoke the lamdba function that ignores the index and invokes the OrderController() constructor. Subsequent invocations of ORDERS.get(...) with the same index will return the element’s content immediately.

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, read JEP 502.

HotSpot

Java 25 introduces two new features in HotSpot:

• Ahead-of-Time Command-Line Ergonomics
• Ahead-of-Time Method Profiling

The HotSpot JVM is the runtime engine that is developed by Oracle. It translates Java bytecode into machine code for the host operating system’s processor architecture.

JEP 514: Ahead-of-Time Command-Line Ergonomics

Java 24 introduced an ahead-of-time cache to store classes in after reading, parsing, loading and linking them. A created cache for a specific application could then be re-used in subsequent runs of that application to improve startup time, by up to 42%.

In Java 24, creating such a cache took two runs of the java process. The first one (the ‘training run’) would record its AOT configuration into the file app.aotconf:

$ java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar com.example.App ...

…and the second one would use the configuration to create the cache into the file app.aot:

$ java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar

But it’s a little inconvenient that creating the cache is currently a two-step process. On top of that, the AOT configuration file just sits there after creation, and isn’t needed any more once the cache has been created.

So that’s why JEP 514 introduces the command-line option AOTCacheOutput, which performs a training run and creates an AOT cache in a single step.

$ java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App ...

As a convenience, when operating in this way the JVM creates a temporary file for the AOT configuration, deleting it when finished. A production run that uses the AOT cache is started the same way as before:

$ java -XX:AOTCache=app.aot -cp app.jar com.example.App ...

For common cases this is a far more convenient way of creating AOT caches. The ability to specify AOT modes and AOT configurations will be retained to support uncommon cases.

More Information

For more information on this feature, read JEP 514.

JEP 515: Ahead-of-Time Method Profiling

The total set of classes that must be loaded for a Java application to run can’t be predicted by the application’s author before starting it. For example, new classes can be loaded in response to external input. So to truly know what a Java application does, we must run it. This observation is supported by Rice’s theorem, which states that “static analysis can always be defeated by program complexity”.

While running an application, the JVM can identify which methods do the important work, and how they do it. For an application to reach peak performance, the JVM’s just-in-time compiler must find the unpredictable set of ‘hot’ methods, i.e., those which consume the most CPU time, and compile their bytecode to native code.

Fun fact: this is actually how the “HotSpot JVM” got its name!

The HotSpot JVM has automatically collected this set of methods in the form of profiles since JDK 1.2. Unfortunately, there is a chicken-and-egg problem: an application cannot achieve peak performance until its method behaviors are predicted, and method behaviors cannot be predicted until the application has run for a significant period of time. This problem is currently solved by dedicating some resources to collecting profiles in the early part of an application’s run. During this ‘warmup period’ the application runs more slowly, until the JIT can compile the hot methods to native code. After warmup, no more methods need to be compiled unless the application changes its pattern of behavior, triggering a new warmup period.

JEP 515 proposes to improve warmup time by collecting profiles even earlier, in a training run of the application, allowing the application to rapidly achieve peak performance. To achieve this the AOT cache is extended to collect method profiles during training runs, that would otherwise be collected in the early part of an application’s run. Accordingly, production runs of the application are both faster to start and faster to achieve peak performance.

Note that profiles cached during training runs do not prevent additional profiling during production runs, since an application’s behavior in production can diverge from what was observed in training. Even with cached profiles, the HotSpot JVM continues to profile and optimize the application as it runs, fusing the benefits of AOT profiles, on-line profiling, and JIT compilation. The net effect of cached profiles is that the JIT runs earlier and with more accuracy, using the profiles to optimize the hot methods so that the application experiences a shorter warmup period. JIT tasks are inherently parallel, so the wall-clock time for warmup can be short when enough hardware resources are available.

To illustrate this, let’s look at a short program that uses the Stream API and thus causes almost 900 JDK classes to loaded. About 30 hot methods are compiled at the highest optimization level:

import java.util.*;
import java.util.stream.*;

public class HelloStreamWarmup {
    static String greeting(int n) {
        var words = List.of("Hello", "" + n, "world!");
        return words.stream()
            .filter(w -> !w.contains("0"))
            .collect(Collectors.joining(", "));
    }

    public static void main(String... args) {
        for (int i = 0; i < 100_000; i++)
            greeting(i);
        System.out.println(greeting(0));  // "Hello, world!"
    }
}

This program runs in 90 milliseconds with an AOT cache that contains no profiles. After collecting profiles into the AOT cache, it runs in 73 milliseconds — an improvement of 19%. The AOT cache with profiles occupies an additional 250 kilobytes, about 2.5% more than the AOT cache without profiles.

A short program such as this has only a short warmup period, but with cached profiles that warmup goes even faster as a result of timely and accurate JIT activity. More complex and longer-running programs are also likely to warm up more quickly, for the same reason.

More Information

For more information on this feature, read JEP 515.

Security Libs

Java 25 introduces a single new feature that is part of the Security Libs:

• PEM Encodings of Cryptographic Objects (Preview)

JEP 470: PEM Encodings of Cryptographic Objects (Preview)

Within a Java context, cryptographic objects such as public keys, private keys and certificates can be easily created and distributed. But outside of the Java world, the de facto standard is the Privacy-Enhanced Mail (PEM) format. Let’s see an example of a PEM-encoded cryptographic object:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEi/kRGOL7wCPTN4KJ2ppeSt5UYB6u
cPjjuKDtFTXbguOIFDdZ65O/8HTUqS/sVzRF+dg7H3/tkQ/36KdtuADbwQ==
-----END PUBLIC KEY-----

The Java Platform currently doesn’t include an easy-to-use API for decoding and encoding text in the PEM format, which means that decoding a PEM-encoded key can be a tedious job that involves careful parsing of the source PEM text. To further illustrate this point, encrypting and decrypting a private key currently requires over a dozen lines of code.

To solve this problem, JEP 470 introduces an API that can encode objects to the PEM format. It effectively acts as a bridge between Base64 and cryptographic objects. It involves a new interface and three new classes, in the java.security package:

DEREncodable

A sealed interface that groups together all cryptographic objects that support converting their instances to and from byte arrays in the Distinguished Encoding Rules (DER) format.

PEMEncoder

A class that declares methods for encoding DEREncodable objects into PEM text.

PEMDecoder

A class that declares methods for decoding PEM text to DEREncodable objects.

PEMRecord

A record that implements DEREncodable, which can hold any type of PEM data. It allows you to encode and decode PEM tests yielding cryptographic objects for which no Java representation currently exists.

Typical Usage

The following code example shows typical usage of the API:

PrivateKey privateKey = ...;
PublicKey publicKey = ...;

// let's encode a cryptographic object!
PEMEncoder pemEncoder = PEMEncoder.of();

// this returns PEM text in a byte array
byte[] privateKeyPem = pemEncoder.encode(privateKey);

// this returns PEM text in a String
String keyPairPem = pemEncoder.encodeToString(new KeyPair(privateKey, publicKey)); 

// this returns encrypted PEM text
String password = "java-first-java-always";
String pem = pemEncoder.withEncryption(password).encodeToString(privateKey);

// let's decode a cryptographic object!
PEMDecoder pemDecoder = PEMDecoder.of();

// this returns a DEREncodable, so we need to pattern-match
switch (pemDecoder.decode(pem)) {
    case PublicKey publicKey -> ...;
    case PrivateKey privateKey -> ...;
    default -> throw new IllegalArgumentException("Unsupported cryptographic object");
}

// alternatively, if you know the type of the encoded cryptographic object in advance:
PrivateKey key = pemDecoder.decode(pem, PrivateKey.class);

// this decodes an encrypted cryptographic object
PrivateKey decryptedkey = pemDecoder.withDecryption(password).decode(pem, PrivateKey.class);

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, read JEP 470.

Java Flight Recorder

Java 25 introduces three new features that are part of the Java Flight Recorder:

• JFR CPU-Time Profiling (Experimental)
• JFR Cooperative Sampling
• JFR Method Timing & Tracing

The Java Flight Recorder is an event recorder built into the JVM. It captures information about the JVM itself – and the applications running in it – not unlike a data flight recorder (or ‘black box’) in a commercial aircraft.

JEP 509: JFR CPU-Time Profiling (Experimental)

Profiling is the act of measuring the consumption of computational resources such as memory, CPU cycles and elapsed time. The resulting measurements can help make a program more efficient, by identifying which program elements to optimize. One would typically prioritize optimizing those elements that consume the most resources.

The Java Flight Recorder (or JFR) is the JDK’s profiling and monitoring facility, commonly used to profile heap memory and CPU usage. Its support of heap allocation profiling is good, but its implementation of CPU profiling currently comes with a few drawbacks:

• it’s only able to approximate CPU-cycle consumption by emitting a sample of running Java threads (in the form of a stacktrace) in a JFR event at regular time intervals (say, every 20 ms);
• it doesn’t include threads that are running native code;
• obtaining the sample may fail without reporting it;
• the sample contains a subset of running threads only.

This means that the resulting profile may be inaccurate and not reflect the actual CPU usage profile, and this effect is amplified when sample collecting occurs over a relatively short period of time.

Towards More Accurate Measurements

Version 2.6.12 of the Linux kernel added the ability to accurately measure CPU-cycle consumption through a timer that emits signals at fixed intervals of elapsed CPU time (rather than real time). JEP 509 enhances the JFR to make use of this timer, producing more accurate CPU-time profiles than could be obtained through the current sampling approach. On top of that, also CPU cycles that are consumed by Java applications running native code would be correctly tracked.

Usage

JFR will use Linux’s CPU-timer mechanism to sample the stack of every thread running Java code at fixed intervals of elapsed CPU time. Each such sample is recorded in a new type of event, called jdk.CPUTimeSample. This event is not enabled by default.

Here’s how to enable the event when running the JFR:

$ java -XX:StartFlightRecording=jdk.CPUTimeSample#enabled=true,filename=profile.jfr ...

Note that his feature will currently only be available on Linux systems. CPU-time profiling may be added to the JFR on other platforms in the future.

More Information

For more information on this feature, read JEP 509. It contains a few more details on how to use the new JFR event and what a typical flame graph would look like.

JEP 518: JFR Cooperative Sampling

We learned in the previous section that the JFR collects samples by obtaining stacktraces for a number of running Java threads. In order to produce these stacktraces, the target threads must be suspended so that the call frames on the stack can be parsed. As part of that process, the Hotspot JVM maintains metadata that is valid only when the thread is suspended at well-defined code locations known as safepoints. However, if sampling is only done at safepoints, the notorious safety bias problem occurs — where accuracy is lost since frequently-executed pieces of code might not be anywhere near a safepoint.

To avoid this problem, the JFR currently samples the stacks of program threads asynchronously, suspending threads at code locations that may not be safepoints at all. This means the metadata maintained by the JVM may not be valid and so we have to resort to using heuristics to generate a stacktrace. Unfortunately, these heuristics are inefficient, and may even crash the JVM when their results are incorrect.

JEP 518 proposes to avoid the need for these heuristics by parsing thread stacks only at safepoints. It comes with a different approach to avoid the safepoint bias problem: taking samples cooperatively. When it is time to take a sample, JFR’s sampler thread still suspends the target thread. But rather than attempting to parse the stack, it just records the target’s program counter and stack pointer in a sample request, which it appends to an internal thread-local queue. It then arranges for the target thread to stop at its next safepoint, and resumes the thread.

The target thread now runs normally until its next safepoint. At that time, the safepoint handling code inspects the queue. If it finds any sample requests, then, for each one, it reconstructs a stack trace, adjusting for safepoint bias, and emits a JFR execution-time sampling event.

More Information

For more information on this feature, read JEP 518.

JEP 520: JFR Method Timing & Tracing

When performance-related problems arise, knowing how much time is spent in which code unit can be very valuable. You may have just introduced a method that takes particularly long to execute. Or a static initializer may cause your application to take an unusually long time to start. In such cases, during development, execution of these code units can be analyzed by using debuggers or the Java Microbenchmark Harness.

However, during testing and production, far less feasible options exist. Sample-based profilers can capture stack traces for frequently executed methods, but can’t provide timing and tracing for all invocations. And the JDK Mission Control tool can certainly instrument methods to emit JFR events, but not without significant performance overhead.

JEP 520 introduces two new JFR events (jdk.MethodTiming and jdk.MethodTrace) that both accept a filter to select the methods to time and trace.

For example, to see what triggers the resize of a HashMap, you can configure the MethodTrace event’s filter when making a recording and then use the jfr tool to display the recorded event:

$ java -XX:StartFlightRecording:jdk.MethodTrace#filter=java.util.HashMap::resize,filename=recording.jfr ...
$ jfr print --events jdk.MethodTrace --stack-depth 20 recording.jfr
jdk.MethodTrace {
    startTime = 00:39:26.379 (2025-03-05)
    duration = 0.00113 ms
    method = java.util.HashMap.resize()
    eventThread = "main" (javaThreadId = 3)
    stackTrace = [
      java.util.HashMap.putVal(int, Object, Object, boolean, boolean) line: 636
      java.util.HashMap.put(Object, Object) line: 619
      sun.awt.AppContext.put(Object, Object) line: 598
      sun.awt.AppContext.<init>(ThreadGroup) line: 240
      sun.awt.SunToolkit.createNewAppContext(ThreadGroup) line: 282
      sun.awt.AppContext.initMainAppContext() line: 260
      sun.awt.AppContext.getAppContext() line: 295
      sun.awt.SunToolkit.getSystemEventQueueImplPP() line: 1024
      sun.awt.SunToolkit.getSystemEventQueueImpl() line: 1019
      java.awt.Toolkit.getEventQueue() line: 1375
      java.awt.EventQueue.invokeLater(Runnable) line: 1257
      javax.swing.SwingUtilities.invokeLater(Runnable) line: 1415
      java2d.J2Ddemo.main(String[]) line: 674
    ]
}

As you can see, the filter is specified just like a method reference. As the JVM starts up, it instruments the targeted method by injecting bytecode to emit a MethodTrace event.

Configuration Files

The JFR is usually configured via a configuration file, which has now also been enhanced to support method timing and tracing. Additionally, the jfr view and jcmd <pid> JFR.view commands have been enhanced to display method timing and tracing results.

To put this all together, if an application suffers from slow startup, timing the execution of all static initializers may suggest where lazy initialization could be used. We can time all static initializers in all classes by omitting the class name, specifying ::<clinit> as the filter:

$ java '-XX:StartFlightRecording:method-timing=::<clinit>,filename=clinit.jfr' ...
$ jfr view method-timing clinit.jfr

                                 Method Timing

Timed Method                                           Invocations Average Time
------------------------------------------------------ ----------- ------------
sun.font.HBShaper.<clinit>()                                     1 32.500000 ms
java.awt.GraphicsEnvironment$LocalGE.<clinit>()                  1 32.400000 ms
java2d.DemoFonts.<clinit>()                                      1 21.200000 ms
java.nio.file.TempFileHelper.<clinit>()                          1 17.100000 ms
sun.security.util.SecurityProviderConstants.<clinit>()           1  9.860000 ms
java.awt.Component.<clinit>()                                    1  9.120000 ms
sun.font.SunFontManager.<clinit>()                               1  8.350000 ms
sun.java2d.SurfaceData.<clinit>()                                1  8.300000 ms
java.security.Security.<clinit>()                                1  8.020000 ms
sun.security.util.KnownOIDs.<clinit>()                           1  7.550000 ms
...

Filtering on Classes and Annotations

To time or trace multiple methods, a filter can mention a class or an annotation. For example, to see the number of times that a Jakarta REST endpoint is invoked, and measure the approximate execution time:

$ jcmd <pid> JFR.start method-timing=@jakarta.ws.rs.GET

Multiple filters can be specified, separated by semicolons.

Benefits

This new approach comes with both performance and usability benefits. As we have seen, the JVM can filter methods, eliminating the need to parse the bytecode of every loaded class twice. And because can methods be timed and traced without having to configure or install an agent, usability improves as well.

More Information

For more information on this feature, read JEP 520.

Repreviews and Finalizations

Now it’s time to take a look at a few features that may already be familiar to you, because they were introduced in a previous version of Java. They have been repreviewed (or finalized) in Java 25, with only minor changes compared to Java 24 in most cases. Therefore, to avoid a very lengthy article, we’ll outline these changes and link to a previous article for a full feature description, should you wish to refresh your memory.

JEP 505: Structured Concurrency (Fifth Preview)

Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.

What’s Different From Java 24?

In Java 25, a StructuredTaskScope can be opened via static factory methods rather than through public constructors. The zero-parameter open() factory method covers the common case by creating a StructuredTaskScope that waits for all subtasks to succeed or any subtask to fail. Other policies and outcomes can be implemented by providing an appropriate Joiner to one of the richer open(Joiner) factory methods.

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

If you prefer to get more information on the current state of this feature, then read JEP 505 or the full feature description from a previous article.

JEP 506: Scoped Values

Scoped values enable the sharing of immutable data within and across threads. They are preferred to thread-local variables, especially when using a large number of (virtual) threads.

What’s Different From Java 24?

A single change was made to the API compared to Java 24:

• The ScopedValue.orElse() method no longer accepts null as its argument.

On top of that, the preview status has been dropped, which means the scoped values API is now finalized!

More Information

For more information on this feature, read JEP 506 or the full feature description from a previous article.

JEP 507: Primitive Types in Patterns, instanceof, and switch (Third Preview)

Pattern matching now supports primitive types in all pattern contexts. On top of that, the instanceof and switch constructs have been extended to also work with all primitive types.

What’s Different From Java 24?

Compared to the preview version of this feature in Java 24, nothing was changed or added. JEP 507 simply exists to gather more feedback from users.

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, read JEP 507 or the full feature description from a previous article.

JEP 508: Vector API (Tenth Incubator)

The Vector API makes it possible to express vector computations that reliably compile at runtime to optimal vector instructions. This means that these computations will significantly outperform equivalent scalar computations on the supported CPU architectures (x64 and AArch64).

What’s Different From Java 24?

The following changes were made to the Vector API compared to Java 23:

• VectorShuffle now supports access to and from MemorySegment;
• The implementation now links to native mathematical-function libraries via the Foreign Function & Memory API (JEP 454) rather than custom C++ code inside the HotSpot JVM, thereby improving maintainability;
• Addition, subtraction, division, multiplication, square root, and fused multiply/add operations on Float16 values are now auto-vectorized on supporting x64 CPUs.

The Vector API will keep incubating until necessary features of Project Valhalla become available as preview features. When that happens, the Vector API will be adapted to use them, and it will be promoted from incubation to preview.

More Information

For more information on this feature, read JEP 508 or the full feature description from a previous article.

JEP 510: Key Derivation Function API

To be able to withstand practical quantum computing attacks, it is Java’s long-term goal is to eventually implement Hybrid Public Key Encryption (HPKE), which facilitates a seamless transition to quantum-resistant encryption methods. To that end, Java 24 introduced a new Key Derivation Function API, which is now finalized in Java 25.

Key derivation functions are cryptographic algorithms for deriving additional keys from a secret key and other data. A KDF allows keys to be created in a manner that is both secure and reproducible by two parties sharing knowledge of the inputs. Deriving keys is similar to hashing passwords. A KDF employs a keyed hash along with extra entropy from its other inputs to either derive new key material or safely expand existing values into a larger quantity of key material.

What’s Different From Java 24?

Compared to the preview version of this feature in Java 24, the preview status has been dropped, which means the Key Derivation Function API is now finalized!

More Information

For more information on this feature, read JEP 510 or the full feature description from a previous article.

JEP 511: Module Import Declarations

Module import declarations import all of the public top-level classes and interfaces in the packages exported by that module. They are a shorter alternative for listing many imports that originate from the same root package.

What’s Different From Java 24?

This feature was in second preview in Java 24, and in Java 25 the preview status has been dropped. This means module import declarations are now finalized!

More Information

For more information on this feature, read JEP 511 or the full feature description from a previous article.

JEP 512: Compact Source Files and Instance Main Methods

Comapct source files allow developers to write Java programs without the need to explicitly declare a class. They can contain ‘instance main methods’: a shorter form of the classic main() method without requiring program arguments or imports. These two features simplify the process of writing small programs and scripts by reducing boilerplate code.

What’s Different From Java 24?

The feature that used to be known as ‘simple source files’ was renamed to ‘compact source files’. On top of that, several minor improvements are now in place based on developer feedback:

• The new IO class for basic console I/O is now in the java.lang package rather than the java.io package. Thus it is implicitly imported by every source file.
• The implementation of the IO class is now based upon System.out and System.in rather than the java.io.Console class.
• The static methods of the IO class are no longer implicitly imported into compact source files. Thus invocations of these methods must name the class, e.g., IO.println("Hello, world!"), unless the methods are explicitly imported.

This last change has been made to make a beginner’s first experience with Java a bit easier. When the static methods of the IO class were automatically imported, this had the pleasing effect of making the methods in IO appear to be built-in to the Java language. However, to evolve a compact source file into an ordinary source file, a beginner would have to add a static import declaration - an advanced concept that a beginner should definitely not tackle on their first day.

More Information

For more information on this feature, read JEP 512 or the full feature description from a previous article.

JEP 513: Flexible Constructor Bodies

Flexible constructor bodies allow statements to appear before an explicit constructor invocation, like super(..) or this(..). The statements cannot reference the instance under construction, but they can initialize its fields. Initializing fields before invoking another constructor makes a class more reliable when methods are overridden.

What’s Different From Java 24?

Compared to the preview version of this feature in Java 24, the preview status has been dropped, which means flexible constructor bodies are now finalized!

More Information

For more information on this feature, read JEP 513 or the full feature description) from a previous article.

JEP 519: Compact Object Headers

JDK 24 introduced compact object headers as an experimental feature, which enabled a reduction of the object header size to 64 bits. Since then, compact object headers have proven their stability and performance. They have been tested at Oracle by running the full JDK test suite. They have also been tested at Amazon by hundreds of services in production, most of them using backports of the feature to JDK 21 and JDK 17. On top of that, various other experiments have demonstrated that enabling compact object headers improves performance.

What’s Different From Java 24?

The experimental status has been dropped, which means compact object headers have now become a product feature. They can be enabled via the command-line options:

$ java -XX:+UseCompactObjectHeaders ...

This means the -XX:+UnlockExperimentalVMOptions option that was required in Java 24 is no longer necessary. In later releases, we can expect the feature to become enabled by default. Eventually the code for legacy object headers will be removed altogether.

More Information

For more information on this feature, including references to the conducted experiments that proved the better performance, read JEP 519 or the full feature description from a previous article.

JEP 521: Generational Shenandoah

The Shenandoah garbage collector is an ultra-low pause time garbage collector. It has been available for production use since Java 15 and has been designed to dramatically reduce garbage collection pause times, regardless of the heap size that is used. It can achieve these low pause times because most of the work is done before the GC pause, in a series of preparation steps. Shenandoah marks and compacts any heap objects eligible for garbage collection, while regular Java user threads are still running.

Java 24 introduced an experimental extension to Shenandoah that maintains separate generations for young and old objects, allowing Shenandoah to collect young objects more frequently. This results in a significant performance gain for applications running with generational Shenandoah, without sacrificing any of the valuable properties that the garbage collector is already known for.

The reason for handling young and old objects separately stems from the weak generational hypothesis, which states that young objects tend to die young, while old objects tend to stick around. This means that collecting young objects requires fewer resources and yields more memory, while collecting old objects requires more resources and yields less memory. This is the reason we can improve the performance of applications that use Shenandoah by collecting young objects more frequently.

What’s Different From Java 24?

The experimental status has now been dropped, which means generational mode has now become a product feature. Compared to JDK 24, many stability and performance improvements have been implemented, and extensive testing on multiple platforms has been performed.

To run your workload with generational Shenandoah in Java 25, the following configuration is needed:

$ java ... -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

This means the -XX:+UnlockExperimentalVMOptions option that was required in Java 24 is no longer necessary. Note that no changes were made to Shenandoah’s default behaviour. This may still change in a future release, though.

More Information

For more information on this feature, read JEP 521 or the full feature description from a previous article.

Deprecations, Removals & Restrictions

Java 25 comes with a single removal.

JEP 503: Remove the 32-bit x86 Port

This JEP removes the 32-bit x86 (Linux) port, which was to be expected after its deprecation in Java 24. The affected users are expected to already have migrated to 64-bit JVMs.

Supporting multiple platforms has been the focus of the Java ecosystem since the beginning. But older platforms cannot be supported indefinitely—the effort that was required to maintain this port exceeded its advantages. Keeping it up-to-date with new features like Loom, the Foreign Function & Memory API (FFM), the Vector API, and late GC barrier expansion represented a significant cost. So it’s time to say goodbye to this port!

More Information

For more information on this removal, read JEP 503.

Final thoughts

And that concludes our discussion of the 18 JEP’s that come with Java 25. But that’s not even all that’s new: many other updates were included in this release, including various performance, stability and security updates. One thing is for sure: this version of Java is ready to perform to the limit. So what are you waiting for? It’s time to take this brand-new Java release for a high-performance spin!

Java 24 brings a diverse set of features, delivering performance improvements like compact object headers, garbage collection optimizations and the first JEP to come out of Project Leyden. On top of that, various security features related to the quantum computing field were added, and a solution to virtual thread pinning is now available!

Apart from these, a few new features from older releases have been repreviewed.

Short descriptions of the repreviewed features are provided to prevent this article from becoming a bit too lengthy. Each repreviewed feature has a link to a longer description of the feature should you wish to learn more.

Photo by Royy Nguyen, from Pexels

JEP Overview

To start off, let’s look at an overview of the JEPs that ship with Java 24. This table contains the preview status for all JEP’s, to which project they belong, what kind of features they add and the things that have changed since Java 23.

New features

Let’s start with the JEP’s that add brand-new features to Java 24.

HotSpot

Java 24 introduces five new features in HotSpot:

• Generational Shenandoah (Experimental)
• Compact Object Headers (Experimental)
• Late Barrier Expansion for G1
• Ahead-of-Time Class Loading & Linking
• Synchronize Virtual Threads Without Pinning

The HotSpot JVM is the runtime engine that is developed by Oracle. It translates Java bytecode into machine code for the host operating system’s processor architecture.

JEP 404: Generational Shenandoah (Experimental)

The Shenandoah garbage collector is an ultra-low pause time garbage collector. It has been available for production use since Java 15 and has been designed to dramatically reduce garbage collection pause times, regardless of the heap size that is used. It can achieve these low pause times because most of the work is done before the GC pause, in a series of preparation steps. Shenandoah marks and compacts any heap objects eligible for garbage collection, while regular Java user threads are still running.

Java 24 introduces an extension to Shenandoah that maintains separate generations for young and old objects, allowing Shenandoah to collect young objects more frequently. This will result in a significant performance gain for applications running with generational Shenandoah, without sacrificing any of the valuable properties that the garbage collector is already known for.

The reason for handling young and old objects separately stems from the weak generational hypothesis, which states that young objects tend to die young, while old objects tend to stick around. This means that collecting young objects requires fewer resources and yields more memory, while collecting old objects requires more resources and yields less memory. This is the reason we can improve the performance of applications that use Shenandoah by collecting young objects more frequently.

Running a Workload With Generational Shenandoah

Shenandoah used to behave in a non-generational way only. Running it required the following command-line configuration:

$ java ... -XX:+UseShenandoahGC

To run your workload with generational Shenandoah in Java 24, the following configuration is needed:

$ java ... -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational

As you can see, generational Shenandoah has been introduced alongside non-generational Shenandoah. In a future release we can expect generational Shenandoah to become the default configuration.

More Information

For more information on this feature, read JEP 404.

JEP 450: Compact Object Headers (Experimental)

A Java object stored in the heap has metadata, which the HotSpot JVM stores in the object’s header. Object headers are a fixed size, occupying between 96 and 128 bits, depending on how the JVM is configured. Since Java objects are often small (typically 256 to 512 bits), object headers can take up over 20% of live data. So reducing the size of object headers can significantly decrease memory footprint and garbage collection pressure. Project Lilliput experiments show a 10%-20% reduction in live data for real-world applications.

JEP 450 proposes to reduce the object header size to 64 bits, by merging the two parts that currently make up the object header: the mark word and the class word.

Legacy Object Header

The mark word comes first, has the size of a machine address, and contains:

Mark Word (normal):
 64                     39                              8    3  0
  [.......................HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH.AAAA.TT]
         (Unused)                      (Hash Code)     (GC Age)(Tag)

The class word comes after the mark word. It takes one of two shapes, depending on whether compressed class pointers are enabled:

Class Word (uncompressed):
64                                                               0
 [cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc]
                          (Class Pointer)

Class Word (compressed):
32                               0
 [CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC]
     (Compressed Class Pointer)

The class word is never overwritten, which means that an object’s type information is always available, so no additional steps are required to check a type or invoke a method.

Compact Object Header

For compact object headers, the division between the mark and class word is removed:

Header (compact):
64                    42                             11   7   3  0
 [CCCCCCCCCCCCCCCCCCCCCCHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHVVVVAAAASTT]
 (Compressed Class Pointer)       (Hash Code)         /(GC Age)^(Tag)
                              (Valhalla-reserved bits) (Self Forwarded Tag)

As you can see, the size of the hash code does not change.

Note that four bits are reserved for future use by Project Valhalla.

Future of This Feature

This experimental feature will have a broad impact on real-world applications. The code might have inefficiencies, bugs, and unanticipated non-bug behaviors. This feature must therefore be disabled by default and enabled only by explicit user request. We can expect the feature to become enabled by default in later releases and eventually the code for legacy object headers will be removed altogether.

Enabling Compact Object Headers

Compact object headers can be enabled as follows:

$ java ... -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders

More Information

For more information on this feature, read JEP 450.

JEP 475: Late Barrier Expansion for G1

The speed of Java applications has become increasingly important with the growing popularity of cloud-based Java deployments. An effective technique for speeding up Java applications is JIT compilation, but it incurs significant overhead in terms of processing time and memory usage. This is particularly noticeable with the C2 compiler which, through its use of early G1 barrier expansion, accounts for up to 20% of the total overhead incurred.

G1? C2? Early Barrier Expansion? Help Me Out Here!

G1 has been Java’s default garbage collector since Java 9. It’s been designed to provide high performance and low pause times for applications with large heaps. It divides the heap into regions and prioritizes garbage collection in regions with the most garbage, hence the name “Garbage-First.” G1 aims to achieve predictable pause times by performing most of its work concurrently with the application threads, minimizing the impact on application performance.

The C2 compiler, also known as the “HotSpot Server Compiler,” is one of the Just-In-Time (JIT) compilers used by the HotSpot JVM in Java. It is designed to optimize and compile Java bytecode into highly optimized machine code at runtime, improving the performance of Java applications. The C2 compiler performs aggressive optimizations, such as inlining, loop unrolling, and escape analysis, to generate efficient native code for performance-critical parts of the application. It is typically used for long-running server applications where performance is crucial.

Barrier expansion is the process of inserting or generating additional code (‘barriers’) that manages memory and ensures the correctness of garbage collection. These barriers are typically inserted at specific points in the byte code, such as before or after memory access, to perform tasks like:

• remembering writes: keeping track of changes to objects, which helps the garbage collector identify which parts of the heap need to be scanned;
• maintaining consistency: ensuring that the program’s view of memory remains consistent with the garbage collector’s view, especially during concurrent garbage collection phases;
• handling references: managing references between objects, particularly when objects are moved during compaction or evacuation phases.

Early barrier expansion simply means that these barriers are inserted or generated early in the compilation process, whereas doing this later in the process (as the JEP proposes) would allow for more optimized placement and potentially reduce the overhead associated with these barriers. This can lead to improved performance and more efficient garbage collection.

More Information

For more information on this feature, read JEP 475. It has more details on the barrier expansion process, and how barrier expansion in the (early) bytecode parsing stage differs from barrier expansion in the (late) code emission stage.

JEP 483: Ahead-of-Time Class Loading & Linking

With features like dynamic class loading, dynamic reflection, dynamic compilation, annotation processing and native code optimization, the Java Platform is a highly dynamic one. To be able to support these dynamic features, the JVM is forced to do a lot of work during startup, like:

• Scanning hundreds of JAR files on disk, while reading and parsing thousands of class files into memory;
• Loading the parsed class data into class objects and linking them together;
• Executing the static initializers of classes, which can create many objects and even perform I/O operations.

If the application uses a framework like Spring, then the startup-time discovery of @Bean, @Configuration, and related annotations will trigger yet more work.

The process described is performed on demand and optimized for quick execution, allowing many Java programs to start in milliseconds. However, larger server applications that utilize web frameworks and various libraries can take seconds or even minutes to launch. Applications often repeat similar tasks during startup, such as scanning JAR files, loading classes, executing static initializers, and configuring application objects using reflection. To enhance startup speed, it’s beneficial to perform some of these tasks proactively rather than waiting until they are needed. This approach aligns with the goals of Project Leyden, which strives to advance certain processes to an earlier stage.

Ahead-of-Time Cache

JEP 483, the first JEP out of Project Leyden, proposes to extend the JVM with an ahead-of-time cache to store classes after reading, parsing, loading and linking them. A created cache for a specific application can be re-used in subsequent runs of that application to improve startup time.

Creating a cache takes two steps. First, you should run the application once in a training run, to record its AOT configuration (in this case into the file app.aotconf):

$ java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar com.example.App ...

Generally speaking, a production run is a good candidate for the training run, as training runs aim to capture application configuration and execution history. In cases where using a production run is impractical (due to activities or accessing databases), it’s recommended to create a synthetic training run that closely resembles production runs, fully configuring itself and testing typical code paths. This can be done by adding a second main class, which invokes the production main class while using a temporary log directory, local network settings, and a mocked database if necessary. You might already have such a main class in the form of an integration test.

Second, use the configuration to create the cache, in the file app.aot:

$ java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar

Subsequently, to run the application with the cache:

$ java -XX:AOTCache=app.aot -cp app.jar com.example.App ...

The AOT cache moves the tasks of reading, parsing, loading, and linking (typically performed just-in-time during program execution) to an earlier stage when the cache is created. As a result, the program starts up more quickly in the execution phase since its classes are readily accessible from the cache.

Performance Improvements of Up To 42%

To illustrate this, let’s look at a short pragram that uses the Stream API and thus causes almost 600 JDK classes to be read, parsed, loaded, and linked:

import java.util.*;
import java.util.stream.*;

public class HelloStream {
    public static void main(String[] args) {
        var words = List.of("hello", "fuzzy", "world");
        var greeting = words.stream()
            .filter(w -> !w.contains("z"))
            .collect(Collectors.joining(", "));
        System.out.println(greeting);  // hello, world
    }
}

This program runs in 0.031 seconds on JDK 23. After doing the small amount of additional work required to create an AOT cache it runs in in 0.018 seconds on JDK 24 — an improvement of 42%. The AOT cache occupies 11.4 megabytes.

For a representative server application, consider Spring PetClinic (v3.2.0). It loads and links about 21,000 classes at startup. It starts in 4.486 seconds on JDK 23 and in 2.604 seconds on JDK 24 when using an AOT cache — coincidentally also an improvement of 42%. Here the AOT cache occupies 130 megabytes.

More Information

For more information on this feature, read JEP 483.

JEP 491: Synchronize Virtual Threads Without Pinning

Virtual threads, available since Java 21, are lightweight threads that are scheduled by the JVM instead of by the operating system. Creating them and disposing of them is fast and cheap, and millions of them can be created within the same JVM.

A virtual thread goes through several stages in its lifetime:

• The virtual thread is created and linked to the code it should run during its lifetime.
• To actually run the code, the virtual thread is mounted on a platform thread, making that platform thread the carrier of the virtual thread.
• After running the code, the virtual thread is unmounted from its carrier and the platform thread is released, so the JDK’s scheduler can mount a different virtual thread on it. Unmounting also happens when a virtual thread performs a blocking operation (such as I/O). When the blocking operation is ready to complete, the virtual thread is submitted back to the JDK’s scheduler, which mounts it on a platform thread again to resume running code.

This means that virtual threads are mounted and unmounted frequently, without blocking any platform threads.

Pinning

But here’s the catch: a virtual thread cannot unmount from its carrier when it runs code inside a synchronized block. Consider the class below, which is run by a virtual thread, tracking the number of customers in a store:

class CustomerCounter {
    private final StoreRepository storeRepo;
    private int customerCount;

    CustomerCounter(StoreRepository storeRepo) {
        this.storeRepo = storeRepo;
        customerCount = 0;
    }

    synchronized void customerEnters() {
        if (customerCount < storeRepo.fetchCapacity()) {
            customerCount++;
        }
    }

    synchronized void customerExits() {
        customerCount--;
    }
}

If the storeRepo.fetchCapacity() method call blocks, it would be nice if the running virtual thread would unmount from its carrier, releasing a platform thread for other virtual threads to be mounted. But customerEnters() is synchronized, and because of this the JVM pins the virtual thread to its carrier, preventing it to be unmounted. The result is that both the virtual thread and the underlying OS thread are blocked, until the result from fetchCapacity() is available.

The Reason For Pinning

synchronized blocks and methods in Java rely on monitors to make sure they can be entered by a single thread at the same time. Before a thread can run a synchronized block, it has to acquire the monitor associated with the instance. The JVM tracks ownership of these monitors on a platform thread level, not on a virtual thread. Given that information, imagine for a moment that pinning didn’t exist. Then in theory, virtual thread #1 could unmount in the middle of a synchronized block, and virtual thread #2 could be mounted on the same platform thread, continuing that same synchronized block because the carrier thread is the same and still holds the object’s monitor. Understandably, the JVM actively prevents this situation!

Overcoming Pinning

So pinning does have a purpose, but frequent pinning for long durations can harm scalability. Because of this, many libraries have switched to using the more flexible java.util.concurrent locks instead, which do not pin virtual threads. But this is a workaround at best, and that’s why JEP 491 proposes to overcome virtual thread pinning.

From Java 24 on, virtual threads can acquire, hold and release monitors, regardless of their carriers. This also means that switching to different locking mechanisms because of thread pinning is no longer necessary. Both approaches will perform equally well with virtual threads from now on.

Remaining Pinning Cases

One of the few remaining situations in which a virtual thread will still be pinned, is when it calls native code, which returns to Java code that performs a blocking operation. In cases like this, the JDK Flight Recorder will record a jdk.VirtualThreadPinned event, should you want to keep track of these situations.

More Information

For more information on this feature, read JEP 491.

Security Libs

Java 24 introduces three new features that are part of the Security Libs:

• Key Derivation Function API (Preview)
• Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
• Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm

JEP 478: Key Derivation Function API (Preview)

As the field of quantum computing advances, traditional cryptographic algorithms are becoming more susceptible to practical attacks. Thus, it is essential for the Java Platform to incorporate Post-Quantum Cryptography (PQC), which can withstand such threats. Java’s long-term goal is to eventually implement Hybrid Public Key Encryption (HPKE), facilitating a seamless transition to quantum-resistant encryption methods. The KEM API (JEP 452), included in JDK 21, serves as one component of HPKE and marks Java’s initial move towards HPKE and readiness for post-quantum challenges. This JEP proposes an additional component of HPKE as a next step in this direction: an API for Key Derivation Functions (KDFs).

KDF’s are cryptographic algorithms for deriving additional keys from a secret key and other data. A KDF allows keys to be created in a manner that is both secure and reproducible by two parties sharing knowledge of the inputs. Deriving keys is similar to hashing passwords. A KDF employs a keyed hash along with extra entropy from its other inputs to either derive new key material or safely expand existing values into a larger quantity of key material.

Operations

A key derivation function has two fundamental operations:

• instantiation and initialization, creating a KDF and initializing it with the appropriate parameters;
• derivation, accepting key material and other optional inputs as well as parameters to describe the output, and generating the derived key or data.

A new class, javax.crypto.KDF represents key derivation functions.

Code Example

To get an idea of how to use this API, see the code example below (taken from the JEP):

// Create a KDF object for the specified algorithm
KDF hkdf = KDF.getInstance("HKDF-SHA256"); 

// Create an ExtractExpand parameter specification
AlgorithmParameterSpec params =
    HKDFParameterSpec.ofExtract()
                     .addIKM(initialKeyMaterial)
                     .addSalt(salt).thenExpand(info, 32);

// Derive a 32-byte AES key
SecretKey key = hkdf.deriveKey("AES", params);

// Additional deriveKey calls can be made with the same KDF object

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, read JEP 478.

JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism

We mentioned quantum computing advancements before in this article, and with good reason. Public-key based algorithms like Rivest-Shamir-Adleman (RSA) and Diffie-Hellman are more and more at risk of practical quantum computing attacks, but they are still in use by the Java Platform (for things like digitally signing JAR files or establishing secure network connections through TLS). To address this issue, quantum-resistant cryptographic algorithms have been invented, and this JEP introduces an implementation of one of those algorithms: the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM).

KEM Components

As described in JEP 452, any key encapsulation mechanism needs the following components:

• a key pair generation function that returns a key pair containing a public key and a private key.
• a key encapsulation function, called by the sender, that takes the receiver’s public key and an encryption option; it returns a secret key and a key encapsulation message. The sender sends the key encapsulation message to the receiver.
• a key decapsulation function, called by the receiver, that takes the receiver’s private key and the received key encapsulation message; it returns the secret key.

The ML-KEM algorithm provides an implementation of the KeyPairGenerator API to generate ML-KEM key pairs. To encapsulate and decapsulate keys, an implementation of the KEM API is provided that negotiates shared secret keys based on an ML-KEM key pair. Also provided is an implementation of the KeyFactory API, that converts ML-KEM keys to and from their encodings.

Furthermore, a new standard algorithm family name (“ML-KEM”) will be defined in the Java Security Standard Algorithm Names Specification. The algorithm comes with three parameter sets (increasing in security, decreasing in performance): “ML-KEM-512”, “ML-KEM-768”, and “ML-KEM-1024”. They are represented by the new NamedParameterSpec constants ML_KEM_512, ML_KEM_768 and ML_KEM_1024.

Generating ML-KEM Key Pairs

You can generate an ML-KEM key pair in one of three ways:

KeyPairGenerator generator = KeyPairGenerator.getInstance("ML-KEM");
generator.initialize(NamedParameterSpec.ML_KEM_512);
KeyPair keyPair = generator.generateKeyPair(); // an ML-KEM-512 key pair

KeyPairGenerator generator = KeyPairGenerator.getInstance("ML-KEM");
KeyPair keyPair = generator.generateKeyPair(); // an ML-KEM-768 key pair by default

KeyPairGenerator generator = KeyPairGenerator.getInstance("ML-KEM-1024");
KeyPair keyPair = generator.generateKeyPair(); // an ML-KEM-1024 key pair

keytool

The keytool command will support generating ML-KEM key pairs and certificates:

$ keytool -keystore ks -storepass changeit -genkeypair -alias ec \
          -keyalg ec -dname CN=ec -ext bc
$ keytool -keystore ks -storepass changeit -genkeypair -alias mlkem \
          -keyalg ML-KEM -groupname ML-KEM-768 -dname CN=ML-KEM -signer ec

The parameter-set name (ML-KEM-768) can also be provided directly with the -keyalg option:

$ keytool -keystore ks -storepass changeit -genkeypair -alias mlkem2 \
          -keyalg ML-KEM-768 -dname CN=ML-KEM2 -signer ec

Encapsulating and Decapsulating Keys

You can use the ML-KEM KEM implementation to negotiate a shared secret key.

For example, a sender can call the encapsulation function to get a secret key and a key encapsulation message:

KEM ks = KEM.getInstance("ML-KEM");
KEM.Encapsulator enc = ks.newEncapsulator(publicKey);
KEM.Encapsulated encap = enc.encapsulate();
byte[] msg = encap.encapsulation();     // send this to receiver
SecretKey sks = encap.key();

A receiver can then call the decapsulation function to recover the secret key from the key encapsulation message sent by the sender:

byte[] msg = ...;                       // received from sender
KEM kr = KEM.getInstance("ML-KEM");
KEM.Decapsulator dec = kr.newDecapsulator(privateKey);
SecretKey skr = dec.decapsulate(msg);

Both sks and skr now contain the same key material, which is known only to the sender and the receiver.

More Information

For more information on this feature, read JEP 496.

JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm

For the exact same reason as the previous JEP, this one introduces an implementation of a different quantum-resistant algorithm: the Module-Lattice-Based Digital Signature Algorithm (ML-DSA).

The ML-DSA algorithm provides an implementation of both the KeyPairGenerator API (to generate ML-DSA key pairs) and the Signature API (to sign and verify ML-DSA signatures). Also provided is an implementation of the KeyFactory API, that converts ML-DSA keys to and from their encodings.

Furthermore, a new standard algorithm family name (“ML-DSA”) will be defined in the Java Security Standard Algorithm Names Specification. The algorithm comes with three parameter sets (increasing in security, decreasing in performance): “ML-DSA-44”, “ML-DSA-65”, and “ML-DSA-87”. They are represented by the new NamedParameterSpec constants ML_DSA_44, ML_DSA_65 and ML_DSA_87.

Generating ML-DSA Key Pairs

You can generate an ML-DSA key pair in one of three ways:

KeyPairGenerator generator = KeyPairGenerator.getInstance("ML-DSA");
generator.initialize(NamedParameterSpec.ML_DSA_44);
KeyPair keyPair = generator.generateKeyPair(); // an ML-DSA-44 key pair

KeyPairGenerator generator = KeyPairGenerator.getInstance("ML-DSA");
KeyPair keyPair = generator.generateKeyPair(); // an ML-DSA-65 key pair by default

KeyPairGenerator generator = KeyPairGenerator.getInstance("ML-DSA-87");
KeyPair keyPair = generator.generateKeyPair(); // an ML-DSA-87 key pair

keytool

The keytool command will support generating ML-DSA key pairs and certificates:

$ keytool -keystore ks -storepass changeit -genkeypair -alias mldsa \
          -keyalg ML-DSA -groupname ML-DSA-65 -dname CN=ML-DSA

$ keytool -keystore ks -storepass changeit -genkeypair -alias mldsa \
          -keyalg ML-DSA-65 -dname CN=ML-DSA2

The parameter-set name (ML-DSA-65) can also be provided directly with the -keyalg option:

$ keytool -keystore ks -storepass changeit -genkeypair -alias mldsa \
          -keyalg ML-DSA-65 -dname CN=ML-DSA2

Signing with ML-DSA Keys

You can use the ML-DSA Signature implementation to sign and verify ML-DSA signatures.

For example, to sign a message using a private key:

byte[] msg = ...;
Signature ss = Signature.getInstance("ML-DSA");
ss.initSign(privateKey);
ss.update(msg);
byte[] sig = ss.sign();

To verify a signature with a public key:

byte[] msg = ...;
byte[] sig = ...;
Signature sv = Signature.getInstance("ML-DSA");
sv.initVerify(publicKey);
sv.update(msg);
boolean verified = sv.verify(sig);

More Information

For more information on this feature, read JEP 497.

Tools

Java 24 contains a single feature that is part of the JLink tool:

• Linking Run-Time Images Without JMODs

JEP 493: Linking Run-Time Images Without JMODs

In cloud environments, container images that include an installed JDK are frequently copied over the network from container registries. Reducing the size of the JDK would improve the efficiency of these operations. This is why the jlink tool can now create custom run-time images without using the JDK’s JMOD files. This allows users to link a run-time image from modules, regardless of their source (be it JMOD files, modular JARs or part of a run-time image linked previously).

Redundancy

An installed JDK consists of a run-time image and a set of packaged modules in the JMOD format, for each module in the run-time image. jlink uses the JMOD files when creating custom run-time images. In fact, the run-time image in the JDK is a result from this very process. That means that every resource in the JDK’s run-time image is also present in one of the JMOD files, which makes an installed JDK suffer from redundancy. The JMOD files account for about 25% of the JDK’s total size. If jlink could be changed to extract resources from the run-time image itself, we could dramatically reduce the size of the JDK by simply omitting these JMOD files.

Build a JDK With --enable-linkable-runtime

The option --enable-linkable-runtime builds a JDK whose jlink tool can create run-time images without using JMOD files. The resulting JDK will have no jmods directory, which means it’s about 25% smaller than before.

$ configure [ ... other options ... ] --enable-linkable-runtime
$ make images

The jlink tool in any JDK build can consume both JMOD files and modular JAR files. In addition, in JDK builds with this feature enabled, jlink can consume modules from the run-time image of which it is part. The --help output of jlink shows whether it has this capability:

$ jlink --help
Usage: jlink <options> --module-path <modulepath> --add-modules <module>[,<module>...]
...
Capabilities:
      Linking from run-time image enabled

So this new capability can be enabled only when building a JDK. This also means that any jlink invocation that wants to make use of it doesn’t need any additional options — it can remain exactly the same. From Java 24 on, jlink will use JMOD files if it can find them on the module path. It will consume modules from the run-time image only if the module java.base is not found on the module path. Any other modules must still be specified to jlink via the --module-path option.

Not enabled by default

This feature is currently not enabled by default, so the default JDK build configuration will remain as it is today. The resulting JDK will contain JMOD files like before and its jlink tool will not be able to operate without them. Whether the JDK build that you get from your preferred vendor contains this feature is up to that vendor. Note that the JEP also states that the feature may be enabled by default in a future release.

More Information

For more information on this feature, read JEP 493.

Repreviews and finalizations

Now it’s time to take a look at a few features that might already be familiar to you, because they were introduced in a previous version of Java. They have been repreviewed (or finalized) in Java 24, with only minor changes compared to Java 23 in most cases. Therefore, to avoid a very lengthy article, we’ll outline these changes and link to a previous article for a full feature description, should you wish to refresh your memory.

JEP 484: Class-File API

Java frameworks often use bytecode transformation to add functionality, relying on libraries like ASM or Javassist. However, the JDK’s six-month release cycle can outpace these libraries, causing compatibility issues. JEP 484 addresses this by proposing a standard class-file API that evolves with the JDK, ensuring up-to-date class file processing.

What’s Different From Java 23?

A few minor things changed to the API, based on feedback from the second preview stage. These changes mainly include the removal of a few fields, methods and interfaces, and the renaming of various enum values, fields and methods. The JEP includes a detailed list on these changes.

More Information

For more information on this feature, read JEP 484 or the full feature description from a previous article.

JEP 485: Stream Gatherers

The Stream API offers a relatively diverse but predetermined range of intermediate operations, including mapping, filtering, sorting and more. JEP 485 introduces stream gatherers, which allow developers to define their own custom intermediate stream operations, so they can transform streams in their own preferred ways.

What’s Different From Java 23?

Nothing was changed, apart from the fact that the API is now finalized in Java 24.

More Information

For more information on this feature, read JEP 485 or the full feature description from a previous article.

JEP 487: Scoped Values (Fourth Preview)

Scoped values enable the sharing of immutable data within and across threads. They are preferred to thread-local variables, especially when using a large number of (virtual) threads.

What’s Different From Java 23?

A single change was made to the API compared to Java 23:

• The callWhere and runWhere methods were removed from the ScopedValue class, which means that the entire API is now fluent. The exact same behavior can be obtained by chaining ScopedValue.where() with run(Runnable) or call(Callable).

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, read JEP 487 or the full feature description from a previous article.

JEP 488: Primitive Types in Patterns, instanceof and switch (Second Preview)

Pattern matching now supports primitive types in all pattern contexts. On top of that, the instanceof and switch constructs have been extended to also work with all primitive types.

What’s Different From Java 23?

Compared to the preview version of this feature in Java 22, nothing was changed or added. JEP 488 simply exists to gather more feedback from users.

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, read JEP 488 or the full feature description from a previous article.

JEP 489: Vector API (Ninth Incubator)

The Vector API makes it possible to express vector computations that reliably compile at runtime to optimal vector instructions. This means that these computations will significantly outperform equivalent scalar computations on the supported CPU architectures (x64 and AArch64).

What’s Different From Java 23?

The following changes were made to the Vector API compared to Java 23:

• A new variation of the selectFrom cross-lane operation now accepts two input vectors, which serve as a lookup table;
• The selectFrom and rearrange cross-lane operations now wrap indexes rather than check for out-of-bounds indexes, making these operations significantly faster.
• Transcendental and trigonometric lanewise operations on ARM and RISC-V are now implemented via intrinsics which call out to the SIMD Library for Evaluating Elementary Functions (SLEEF).
• The new value-based class Float16 represents 16-bit floating-point numbers in the IEEE 754 binary16 format.
• The arithmetic integral lanewise operations now include saturating unsigned addition and subtraction, saturating signed addition and subtraction, and unsigned maximum and minimum.

The Vector API will keep incubating until necessary features of Project Valhalla become available as preview features. When that happens, the Vector API will be adapted to use them, and it will be promoted from incubation to preview.

More Information

For more information on this feature, read JEP 489 or the full feature description from a previous article.

JEP 492: Flexible Constructor Bodies (Third Preview)

Flexible constructor bodies allow statements to appear before an explicit constructor invocation, like super(..) or this(..). The statements cannot reference the instance under construction, but they can initialize its fields. Initializing fields before invoking another constructor makes a class more reliable when methods are overridden.

Preview Warning

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

What’s Different From Java 23?

Compared to the preview version of this feature in Java 23, no significant changes were made. JEP 492 simply exists to gather more feedback from users.

More Information

For more information on this feature, read JEP 492 or the full feature description from a previous article.

JEP 494: Module Import Declarations (Second Preview)

Module import declarations import all of the public top-level classes and interfaces in the packages exported by that module. They are a shorter alternative for listing many imports that originate from the same root package.

What’s Different From Java 23?

This feature is repreviewed in Java 24, with two additions:

• The restriction that no module is able to declare a transitive dependency on the java.base module is lifted, and the declaration of the java.se module to transitively require the java.base module is revised. With these changes, importing the java.se module will import the entire Java SE API on demand.
• Type-import-on-demand declarations to shadow module import declarations are now allowed.

More Information

For more information on this feature, read JEP 494 or the full feature description from a previous article.

JEP 495: Simple Source Files and Instance Main Methods (Fourth Preview)

Simple source files allow developers to write Java programs without the need to explicitly declare a class. They can contain ‘instance main methods’: a shorter form of the classic main() method without requiring program arguments or imports. These two features simplify the process of writing small programs and scripts by reducing boilerplate code.

What’s Different From Java 23?

The two features in this JEP didn’t change in Java 24; however, the feature that used to be known as ‘implicitly declared classes’ was renamed to ‘simple source files’.

More Information

For more information on this feature, read JEP 495 or the full feature description from a previous article.

JEP 499: Structured Concurrency (Fourth Preview)

Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.

What’s Different From Java 23?

Nothing was changed, the API is re-previewed in Java 24 to give more time for feedback from real world usage.

However, significant API changes are scheduled to appear in a future Java release. A StructuredTaskScope will then be opened via static factory methods rather than through public constructors. The zero-parameter open() factory method will cover the common case by creating a StructuredTaskScope that waits for all subtasks to succeed or any subtask to fail. Other policies and outcomes can be implemented by providing an appropriate Joiner to one of the richer open(Joiner) factory methods.

If you’re interested in the future of this feature, JEP draft #8340343 has more details on these upcoming API changes.

More Information

If you prefer to get more information on the current state of this feature, then read JEP 499 or the full feature description from a previous article.

Deprecations & Restrictions

Java 24 also deprecates a few older features that weren’t used that much and restricts a few other features that came with certain risks. Let’s see which ones were involved in this effort to improve stability.

JEP 472: Prepare to Restrict the Use of JNI

The Java Native Interface has been the factory standard of invoking foreign functions (outside of the JVM but on the same machine) for many years now. In Java 22 a more modern approach became available: the Foreign Function & Memory API. Although the new FFM API is the preferred alternative to JNI, that doesn’t mean that JNI will be phased out. On the contrary, the Java language designers want to make sure that migrating from one to the other can be done easily. To make that happen, this JEP introduces certain warnings to JNI to mirror the warnings that the FFM API already produces.

To be more precise, calling native code via JNI requires you to load a native library first and link a Java construct to a function in that library. JEP 472 will add the restrictions that the FFM API already imposes on these loading and linking steps to JNI also. All warnings of this type aim to prepare developers for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API.

More Information

For more information on this feature, read JEP 472.

JEP 486: Permanently Disable the Security Manager

The Security Manager has not been the primary method for securing client-side Java code for many years and is seldom used for server-side code. It is also costly to maintain. Consequently, it was deprecated for removal in Java 17 via JEP 411. JEP 486 takes the next logical step: developers are now prevented from enabling the Security Manager at all. The Java Language Designers feel this is a safe step to take, as the deprecation in Java 17 hardly had any impact. The Security Manager API will be removed in a future release.

OK, But What Exactly Is the Security Manager?

That is a fair question, because it has rarely been used. The Security Manager, a feature since Java’s first release, operates on the principle of least privilege: code is untrusted by default, so it cannot access resources such as the filesystem or the network. This restricts code access to resources unless explicitly granted permission. Despite its theoretical benefits, its complexity has led to it being rarely used and has always been disabled by default. The least-privilege model adds significant complexity to Java Platform libraries, requiring over 1,000 methods to check permissions and over 1,200 methods to elevate privileges when the Security Manager is enabled.

More Information

For more information on this change, read JEP 486.

JEP 490: ZGC: Remove the Non-Generational Mode

The Z Garbage Collector (ZGC) is a scalable, low-latency garbage collector. It has been available for production use since Java 15 and has been designed to keep pause times consistent and short, even for very large heaps. It uses techniques like region-based memory management and compaction to achieve this.

Java 21 introduced an extension to ZGC that maintains separate generations for young and old objects, allowing ZGC to collect young objects (which tend to die young) more frequently. This will result in a significant performance gain for applications running with generational ZGC, without sacrificing any of the valuable properties that the Z garbage collector is already known for. Java 23 made generational mode the default mode for ZGC and deprecated non-generational mode. Java 24 removes non-generational mode altogether.

How Do the ZGC Command-Line Options Work After This Change?

In Java 23, the following command would use generational mode by default:

$ java -XX:+UseZGC ...

This behavior is still the same in Java 24. Also, in Java 24, if you would run Java with the now-obsolete option ZGenerational…

$ java -XX:+UseZGC -XX:-ZGenerational ...

…an obsolete-option warning will be printed.

More Information

For more information on this feature, read JEP 490.

JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe

The sun.misc.Unsafe class contains 87 methods to perform low-level operations, such as accessing off-heap memory. The class is aptly named: using its methods without performing the necessary safety checks can lead to undefined behaviour and to the JVM crashing. They were meant exclusively for use within the JDK, but back in 2002 when the class was introduced the module system wasn’t around yet and so there was no way to prevent the class from being used outside the JDK. Thus, the memory-access methods in sun.misc.Unsafe became a valuable tool for library developers seeking greater power and performance than what standard APIs could provide.

Two standard APIs have emerged in recent years that are far better alternatives to these problematic methods:

• java.lang.invoke.VarHandle, to manipulate on-heap memory safely and efficiently;
• java.lang.foreign.MemorySegment, to access off-heap memory safely and efficiently.

Given the situation, Java 23 already deprecated the memory-access methods, which led to Java generating compile-time warnings whenever these methods were used. JEP 490 extends this behavior by also generating run-time warnings for any use of these methods.

JDK 24 will, by default, issue a warning on the first occasion that any memory-access method is used, whether directly or via reflection. That is, it will issue at most one warning regardless of which memory-access methods are used and how many times any particular method is used. This will alert application developers and users to the forthcoming removal of the methods, and the need to upgrade libraries. An example of the warning is:

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::setMemory has been called by com.foo.bar.Server (file:/tmp/foobarserver/thing.jar)
WARNING: Please consider reporting this to the maintainers of com.foo.bar.Server
WARNING: sun.misc.Unsafe::setMemory will be removed in a future release

A future release of Java will start throwing exceptions in these situations. In an even later Java release the methods will be removed entirely. According to the JEP text the entire process won’t be completed until after the release of JDK 26, giving developers ample time to adjust to the new situation.

More Information

For more information on this feature, see JEP 498. It has more details on the targeted methods, their alternatives from VarHandle and MemorySegment and how to configure the deprecation warnings with the new command-line option --sun-misc-unsafe-memory-access (to promote the warnings to UnsupportedOperationExceptions already, for example). It also provides a few migration examples.

JEP 501: Deprecate the 32-bit x86 Port for Removal

Supporting multiple platforms has been the focus of the Java ecosystem since the beginning. But older platforms cannot be supported indefinitely, and that is one of the reasons why the 32-bit x86 (Linux) port is now scheduled for removal. The effort that was required to maintain this port exceeded its advantages. Keeping it up-to-date with new features like Loom, the Foreign Function & Memory API (FFM), the Vector API, and late GC barrier expansion represented a significant cost, so it is now deprecated.

Configuring a 32-bit x86 build will now fail on JDK 24. This error can be suppressed by using the new build configuration option --enable-deprecated-ports=yes. This means 32-bit users can still use JDK 24; however a future release will actually remove the support, and by that time the affected users are expected to have migrated to 64-bit JVMs.

More Information

For more information on this deprecation, read JEP 501.

JEP 479: Remove the Windows 32-bit x86 Port

This JEP removes the Windows 32-bit x86 port, which was to be expected after its deprecation in Java 21. This is due to the fact that Windows 10, the last Windows operating system to support 32-bit operation, will reach end-of-life in October 2025. On top of that, the implementation of virtual threads on Windows 32-bit x86 is rudimentary to say the least: it uses a single platform thread for each virtual thread, effectively rendering the feature useless on this platform. So it’s time to say goodbye to this port!

More Information

For more information on this removal, read JEP 479.

Final thoughts

And that concludes our discussion of the 24 JEP’s that come with Java 24. But that’s not even all that’s new: many other updates were included in this release, including various performance, stability and security updates. So what are you waiting for? Time to take this brand-new Java release for a spin!

Image from PxHere

From Project Amber

Java 23 contains 4 features that originated from Project Amber:

• Primitive Types in Patterns, instanceof, and switch (Preview)
• Module Import Declarations (Preview)
• Implicitly Declared Classes and Instance Main Methods (Third Preview)
• Flexible Constructor Bodies (Second Preview)

The goal of Project Amber is to explore and incubate smaller, productivity-oriented Java language features.

JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)

Pattern matching has become more prominent in Java since Java 16, but its support for primitives was always limited to nested record patterns. This JEP proposes to support primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types.

Pattern Matching for Switch

Pattern matching for switch currently doesn’t support type patterns that specify a primitive type. This JEP proposes to add support for primitive type patterns in switch, allowing the following code example:

switch (reverb.roomSize()) {
    case 1 -> "Toilet";
    case 2 -> "Bedroom";
    case 30 -> "Classroom";
    default -> "Unsupported value: " + reverb.roomSize();
}

…to be written as follows:

switch (reverb.roomSize()) {
    case 1 -> "Toilet";
    case 2 -> "Bedroom";
    case 30 -> "Classroom";
    case int i -> "Unsupported int value: " + i;
}

This also allows guards to inspect the matched value, like so:

switch (reverb.roomSize()) {
    case 1 -> "Toilet";
    case 2 -> "Bedroom";
    case 30 -> "Classroom";
    case int i when i > 100 && i < 1000 -> "Cinema";
    case int i when i > 5000 -> "Stadium";
    case int i -> "Unsupported int value: " + i;
}

Record Patterns

Record patterns currently have limited support for primitive types. Recall that a record pattern decomposes a record into its individual components, but when one of them is a primitive type, the record pattern must be precise about its type. To illustrate this point, consider the following code example:

record Tuner(double pitchInHz) implements Effect {}

var tuner = new Tuner(440); // int argument is widened to double

// Attempt 1: record pattern match on int argument
if (tuner instanceof Tuner(int p)) {} // doesn't compile!

// Attempt 2: record pattern match on double argument
if (tuner instanceof Tuner(double p)) {
    int pitch = p; // doesn't compile! needs a cast to int
}

// Attempt 3: record pattern match on double argument, cast to int
if (tuner instanceof Tuner(double p)) {
    int pitch = (int) p;
}

To put it differently, the Java compiler widens the provided int to a double, but it doesn’t narrow it back to an int. This limitation exists because narrowing could lead to data loss: the value of the double at runtime might exceed the range of an int or have more precision than an int can accommodate. However, one significant advantage of pattern matching is its ability to automatically reject invalid values by not matching them at all. If the double component of a Tuner is either too large or too precise to safely convert back to an int, then instanceof Tuner(int p) would simply return false, allowing the program to manage the large double component in a different code branch.

This is analogous to how pattern matching currently behaves for reference type patterns. For example:

record SingleEffect(Effect effect) {}
var singleEffect = new SingleEffect(...);

if (singleEffect instanceof SingleEffect(Delay d)) {
    // ...
} else if (singleEffect instanceof SingleEffect(Reverb r)) {
    // ...
} else {
    // ...
}

instanceof can be used here to try to match a SingleEffect with a Delay or a Reverb component; it automatically narrows if the pattern matches.

To summarize, this JEP proposes to make primitive type patterns work as smoothly as reference type patterns, allowing Tuner(int p) even if the corresponding record component is a numeric primitive type other than int.

Pattern Matching for instanceof

Pattern matching for instanceof currently doesn’t support primitive type patterns, but this capability would perfectly align with the purpose of instanceof: to test whether a value can be converted safely to a given type. To convert primitives safely, Java developers currently have to deal with lossy casts and range checks to prevent loss of information:

int roomSize = reverb.roomSize();

if (roomSize >= -128 && roomSize < 127) {
    byte r = (byte) roomSize;
    // now it's safe to use r
}

This JEP proposes the possibility to replace these constructs with simple instanceof checks that operate on primitives. Let’s rewrite the code example to make use of this feature:

int roomSize = reverb.roomSize();

if (roomSize instanceof byte r) {
    // now it's safe to use r
}

The pattern roomSize instanceof byte r will match only if roomSize fits into a byte, eliminating the need for casts and range checks.

Primitive Types in instanceof

The instanceof keyword used to take a reference type only, and since Java 16 it can also take a type pattern. But it would make sense to have instanceof take a primitive type also. In that case instanceof would check if the conversion is safe but would not actually perform it:

if (roomSize instanceof byte) { // check if value of roomSize fits in a byte
    ... (byte) roomSize ... // yes, it fits! but cast is required
}

This JEP proposes to support this construct, which makes it easier to change the instanceof check to take a type pattern and vice versa.

Primitive Types in switch

The switch statement/expression currently supports byte, short, char, and int values. This JEP proposes to also add support for the other primitive types: boolean, float, double and long. A switch on a boolean value can be a good alternative for the ternary operator (?:), because its branches can also hold statements instead of just expressions.

String guitaristResponse = switch (guitar.isInTune()) {
    case true -> "Ready to play a song.";
    case false -> {
        log.warn("Guitar is out of tune!");
        yield "Let's take five!";
    }
}

What’s Different From Java 22?

Java 22 didn’t support primitive types in patterns, instanceof and switch yet. Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, see JEP 455.

JEP 476: Module Import Declarations (Preview)

Many essential classes in the Java Class Library require imports to be usable. In the following code, for example…

import java.util.Map;                   // or import java.util.*;
import java.util.function.Function;     // or import java.util.function.*;
import java.util.stream.Collectors;     // or import java.util.stream.*;
import java.util.stream.Stream;         // 

String[] instruments = new String[] { "violin", "piano", "marimba" };
Map<String, String> m =
    Stream.of(instruments)
          .collect(Collectors.toMap(s -> s.toUpperCase().substring(0, 1), Function.identity()));

…the imports take up just as much space as the code itself.

Whether that’s a bad thing or not depends on your import type preference. In large, mature projects single-type imports are preferred by many. However, in early-stage situations (when trying out a new feature, or when you’re in JShell) a more convenient approach could come in handy.

Module Import Declarations

This JEP introduces module import declarations, and they have the form import module M;. A module import declaration imports all of the public top-level classes and interfaces in the packages exported by the module M to the current module. Any indirect exports by the module M will also be made available by a module import declaration.

For example, if you write import module java.sql, it means your class will be able to read classes and interfaces from the packages java.sql and javax.sql (because they are exported by the module java.sql). On top of that, because java.sql pulls in three other modules transitively, any exported packages from those modules will also be available.

Ambiguous Imports

When you import a module, it brings in several packages, which means you might end up importing classes that have the same simple name from different packages. This creates ambiguity, leading to a compile-time error.

In this source file, the simple name Date is ambiguous:

import module java.base;      // exports java.util, which has a public Date class
import module java.sql;       // exports java.sql, which has a public Date class

...
Date d = ...                  // Error - Ambiguous name!
...

Resolving ambiguities is straightforward: use a single-type-import declaration. For example, to resolve the ambiguous Date of the previous example:

import module java.base;      // exports java.util, which has a public Date class
import module java.sql;       // exports java.sql, which has a public Date class

import java.sql.Date;         // resolve the ambiguity of the simple name Date

...
Date d = ...                  // Ok! Date is resolved to java.sql.Date
...

What’s Different From Java 22?

Up until Java 22, to import all public top-level classes and interfaces from a module, a wildcard-type import was required for each package in the module. In Java 23 the same behaviour can be achieved using a single module import declaration. Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, see JEP 476.

JEP 477: Implicitly Declared Classes and Instance Main Methods (Third Preview)

Java’s take on the classic Hello, World! program is notoriously verbose:

public class HelloWorld { 
    public static void main(String[] args) { 
        System.out.println("Hello, World!");
    }
}

On top of that, it forces newcomers to grasp a few concepts that they certainly don’t need on their first day of Java programming:

• The public access modifier and its role in encapsulating units of code, together with its counterparts private, protected and default;
• The String[] args parameter, that allows the operating system’s shell to pass arguments to the program;
• The static modifier and how it’s part of Java’s class-and-object model;
• How to import basic utility classes, to prevent the need for the mysterious System.out.println incantation.

The motivation for this JEP is to help programmers that are new to Java by introducing concepts in the right order, starting with the more fundamental ones. This is done by hiding any unnecessary details until they are useful in larger programs.

Proposed Changes

To achieve this, the JEP proposes the following changes:

• change the launch protocol to allow instance main methods, which are not static and don’t need a public modifier, nor a String[] parameter;

class HelloWorld { 
    void main() { // this is an instance main method
        System.out.println("Hello, World!");
    }
}

• allow a compilation unit to implicitly declare a class:

void main() { // this is an instance main method in an implicitly declared class
    System.out.println("Hello, World!");
}

• in implicitly declared classes, automatically import useful methods for textual input and output, thereby avoiding the mysterious System.out.println:

void main() {
    println("Hello, World!"); // this method is automatically imported
}

A Flexible Launch Protocol

Java 23 enhances the launch protocol to offer more flexibility in declaring a program’s entry point. The main method of a launched class can now have public, protected or default access. Other enhancements of the launch protocol include:

• If the launched class contains a main method with a String[] parameter, then choose that method.
• Otherwise, if the class contains a main method with no parameters, then choose that method.
• In either case, if the chosen method is static, then simply invoke it.
• Otherwise, the chosen method is an instance method and the launched class must have a zero-parameter, non-private constructor. Invoke that constructor and then invoke the main method of the resulting object. If there is no such constructor, then report an error and terminate.
• If there is no suitable main method, then report an error and terminate.

Implicitly Declared Classes

With the introduction of implicitly declared classes, the Java compiler will consider a method that is not enclosed in a class declaration, as well as any unenclosed fields and any classes declared in the file, to be members of an implicitly declared top-level class. Such a class always belongs to the unnamed package, is final, and can’t implement interfaces or extend classes except Object. You can’t reference it by name or use method references for its static methods, but you can use this and make method references to its instance methods. Implicitly declared classes can’t be instantiated or referenced by name in code. They’re mainly used as program entry points and must have a main method, enforced by the Java compiler.

Interacting with the Console

Many beginner programs need to interact with the console, for example:

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

class Main {
    public static void main(String... args) {
        System.out.println("Please enter your name:");
        String name = "";
        try {
            BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
            name = reader.readLine();
        } catch (IOException ioe) {
            ioe.printStackTrace();
        }
        System.out.println("Hello, " + name);
    }
}

The code may seem familiar to experienced developers, but beginners often find it confusing due to new concepts like import, try, catch, BufferedReader, InputStreamReader and IOException. While there are other approaches, none are significantly better for those just starting out.

To make interacting with the console easier for beginners, implicit classes now automatically import all static methods from the newly added class java.io.IO:

• public static void println(Object obj);
• public static void print(Object obj);
• public static String readln(String prompt);

Combined with the other features from this JEP, the code above can now be simplified to:

void main() {
    String name = readln("Please enter your name:");
    print("Hello, ");
    println(name);
}

Automatic Import of the java.base Module

To make writing small programs even easier, all public top-level classes and interfaces from the java.base module are now automatically available in every implicit class, as if they were imported. This means that popular APIs from packages like java.io, java.math, and java.util can be used right away, eliminating the need for explicit import statements that might confuse beginners.

This implicit behaviour can also be made explicit to make it work in any other class, by using a module import declaration like import module java.base, which can be helpful when converting an implicit class to a top-level class.

What’s Different From Java 22?

Java 23 contains the following changes compared to Java 22:

• Implicitly declared classes automatically import three static methods for simple textual I/O with the console. These methods are declared in the new top-level class java.io.IO.
• Implicitly declared classes automatically import, on demand, all of the public top-level classes and interfaces of the packages exported by the java.base module.

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, see JEP 477.

JEP 482: Flexible Constructor Bodies (Second Preview)

Suppose we have a superclass Orchestra and a subclass StringQuartet. The constructors of these classes must work together to ensure a valid instance. The StringQuartet constructor is responsible for any StringQuartet-specific fields, while the Orchestra constructor is responsible for fields declared in the Orchestra class. Since code in the StringQuartet constructor might refer to fields initialized by the Orchestra constructor, the latter must run first.

This example illustrates that constructors should run from top to bottom. This also means that a superclass constructor must finish initializing its fields before a subclass constructor starts, ensuring proper object state initialization and preventing access to uninitialized fields. Java enforces this by requiring explicit constructor calls (like super(...) or this(...)) to be the first statement in a constructor body, and constructor arguments cannot access the current object. While these rules ensure that constructors behave predictably, they may restrict the use of common programming patterns in constructor methods. The following code example illustrates this point:

class StringQuartet extends Orchestra {
    public StringQuartet(List<Instrument> instruments) {
        super(instruments); // Potentially unnecessary work!

        if (instruments.size() != 4) {
            throw new IllegalArgumentException("Not a quartet!");
        }
    }
}

It would be better to let the constructor fail fast, by validating its arguments before the super(...) constructor is called. Pre-Java 22, we could only achieve this by introducing a static method that acts upon the value passed to the super constructor.

public class StringQuartet extends Orchestra {
    public StringQuartet(List<Instrument> instruments) {
        super(validate(instruments));
    }

    private static List<Instrument> validate(List<Instrument> instruments) {
        if (instruments.size() != 4) {
            throw new IllegalArgumentException("Not a quartet!");
        }
    }
}

But a far more readable way to write the same would be:

public class StringQuartet extends Orchestra {
    public StringQuartet(List<Instrument> instruments) {
        if (instruments.size() != 4) {
            throw new IllegalArgumentException("Not a quartet!");
        }

        super(instruments);
    }
}

This approach will be possible in Java 23, due to the introduction of early construction contexts. Java used to treat the arguments to an explicit constructor invocation to be in a static context, as if they were in a static method. But this restriction is a bit stronger than necessary, which is why Java 23 introduces the aforementioned early construction contexts; a strictly weaker concept. It covers both the arguments to an explicit constructor invocation and any statements that occur before it. Code in an early construction context must not use the instance under construction, except to initialize fields that do not have their own initializers.

What’s Different From Java 22?

• The feature was renamed: in Java 22 it was known as “Statements before super(…)”;
• A constructor body is now allowed to initialize fields in the same class before explicitly invoking a constructor. This possibility prevents any superclass constructor from seeing the default value of a subclass field (like 0, false or null).

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, see JEP 482.

What Happened to String Templates?

Java 22 had a feature called string templates, which was in second preview back then. However, the feature is not included in Java 23, which might be surprising, but at the same time it’s a valid possibility. We have always known that preview features are impermanent, and might even be removed instead of promoted to ‘final’ status.

So what happened? Well, in short: the effort did not meet the needs of the developers. Like any preview feature, feedback was received from the developer community, and quite a few issues were raised. Some remarks were about syntax, and others were about nested templates. But the most relevant feedback was about the co-dependence of string templates and template processors. To make the feature perform better than String.format(...), it was crucial that the template processor would appear close to the string template it had to process, which is why the special syntax PROCESSOR."template" was introduced. Based on the feedback, on the Project Amber mailing list a discovery was made: the template and the code processing it didn’t have to appear side by side to achieve the performance boost. This meant that the special syntax could also potentially be dropped. This realization ultimately sent the feature back to the drawing board! While the new direction was taking shape, the Java 23 deadline was fast approaching and the choice was made to drop the feature entirely, instead of repreviewing it unchanged while everyone knew the design would change drastically in the future.

What Happens Next?

So, what happens next? Well, a new JEP will probably appear in the future, but it might take a while, as much of the initial design has to be reconsidered. But based on the above template processors probably won’t have a prominent place. And string templates will probably become a new kind of literal (similar to String literals), because there’s no need for them to be tied to their template processor any more. There’s no way for us to know exactly when a new proposal will be ready, so we’ll just have to wait and see. And in the meantime, if you’re interested, this excellent video by Nicolai Parlog has a few more interesting details to keep you occupied.

From Project Loom

Java 23 contains 2 features that originated from Project Loom:

• Structured Concurrency (Third Preview)
• Scoped Values (Third Preview)

Project Loom strives to simplify maintaining concurrent applications in Java by introducing virtual threads and an API for structured concurrency, among other things.

JEP 480: Structured Concurrency (Third Preview)

Java’s take on concurrency has always been unstructured, meaning that tasks run independently of each other. There’s no hierarchy, scope, or other structure involved, which means errors or cancellation intent is hard to communicate. To illustrate this, let’s look at a code example that takes place in a restaurant:

The code examples that illustrate Structured Concurrency were taken from my conference talk “Java’s Concurrency Journey Continues! Exploring Structured Concurrency and Scoped Values”.

public class MultiWaiterRestaurant implements Restaurant {
    @Override
    public MultiCourseMeal announceMenu() throws ExecutionException, InterruptedException {
        Waiter grover = new Waiter("Grover");
        Waiter zoe = new Waiter("Zoe");
        Waiter rosita = new Waiter("Rosita");

        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            Future<Course> starter = executor.submit(() -> grover.announceCourse(CourseType.STARTER));
            Future<Course> main = executor.submit(() -> zoe.announceCourse(CourseType.MAIN));
            Future<Course> dessert = executor.submit(() -> rosita.announceCourse(CourseType.DESSERT));

            return new MultiCourseMeal(starter.get(), main.get(), dessert.get());
        }
    }
}

Note that the announceCourse(..) method in the Waiter class sometimes fails with an OutOfStockException, because one of the ingredients for the course might not be in stock. This can lead to some problems:

• If zoe.announceCourse(CourseType.MAIN) takes a long time to execute but grover.announceCourse(CourseType.STARTER) fails in the meantime, the announceMenu(..) method will unnecessarily wait for the main course announcement by blocking on main.get(), instead of cancelling it (which would be the sensible thing to do).
• If an exception happens in zoe.announceCourse(CourseType.MAIN), main.get() will throw it, but grover.announceCourse(CourseType.STARTER) will continue to run in its own thread, resulting in thread leakage.
• If the thread executing announceMenu(..) is interrupted, the interruption will not propagate to the subtasks: all threads that run an announceCourse(..) invocation will leak, continuing to run even after announceMenu() has failed.

Ultimately the problem here is that our program is logically structured with task-subtask relationships, but these relationships exist only in the mind of the developer. We might all prefer structured code that reads like a sequential story, but this example simply doesn’t meet that criterion.

In contrast, the execution of single-threaded code always enforces a hierarchy of tasks and subtasks, as shown by the single-threaded version of our restaurant example:

public class SingleWaiterRestaurant implements Restaurant {
    @Override
    public MultiCourseMeal announceMenu() throws OutOfStockException {
        Waiter elmo = new Waiter("Elmo");

        Course starter = elmo.announceCourse(CourseType.STARTER);
        Course main = elmo.announceCourse(CourseType.MAIN);
        Course dessert = elmo.announceCourse(CourseType.DESSERT);

        return new MultiCourseMeal(starter, main, dessert);
    }
}

Here, we don’t have any of the problems we had before. Our waiter Elmo will announce the courses in exactly the right order, and if one subtask fails the remaining one(s) won’t even be started. And because all work runs in the same thread, there is no risk of thread leakage.

It became apparent from these examples that concurrent programming would be a lot easier and more intuitive if enforcing the hierarchy of tasks and subtasks was possible, just like with single-threaded code.

Introducing Structured Concurrency

In a structured concurrency approach, threads have a clear hierarchy, their own scope, and clear entry and exit points. Structured concurrency arranges threads hierarchically, akin to function calls, forming a tree with parent-child relationships. Execution scopes persist until all child threads complete, matching code structure.

Shutdown on Failure

Let’s now take a look at a structured, concurrent version of our example:

public class StructuredConcurrencyRestaurant implements Restaurant {
    @Override
    public MultiCourseMeal announceMenu() throws ExecutionException, InterruptedException {
        Waiter grover = new Waiter("Grover");
        Waiter zoe = new Waiter("Zoe");
        Waiter rosita = new Waiter("Rosita");

        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
            Supplier<Course> starter = scope.fork(() -> grover.announceCourse(CourseType.STARTER));
            Supplier<Course> main = scope.fork(() -> zoe.announceCourse(CourseType.MAIN));
            Supplier<Course> dessert = scope.fork(() -> rosita.announceCourse(CourseType.DESSERT));

            scope.join(); // 1
            scope.throwIfFailed(); // 2

            return new MultiCourseMeal(starter.get(), main.get(), dessert.get()); // 3
        }
    }
}

The scope’s purpose is to keep the threads together. At 1, we wait (join) until all threads are done with their work. If one of the threads is interrupted, an InterruptedException is thrown here. At 2, an ExecutionException is thrown if an exception occurs in one of the threads. Once we reach 3, we can be sure everything has gone well, and we can retrieve and process the results.

Actually, the main difference with the code we had before is the fact that we create threads (fork) within a new scope. Now we can be certain that the lifetimes of the three threads are confined to this scope, which coincides with the body of the try-with-resources statement.

Furthermore, we’ve gained short-circuiting behaviour. When one of the announceCourse(..) subtasks fails, the others are cancelled if they didn’t complete yet. This behaviour is managed by the ShutdownOnFailure policy. We’ve also gained cancellation propagation. When the thread that runs announceMenu() is interrupted before or during the call to scope.join(), all subtasks are cancelled automatically when the thread exits the scope.

Shutdown on Success

A shutdown-on-failure policy cancels tasks if one of them fails, while a shutdown-on-success policy cancels tasks if one succeeds. The latter is useful to prevent unnecessary work once a successful result is obtained.

Let’s see what a shutdown-on-success implementation would look like:

public record DrinkOrder(Guest guest, Drink drink) {}

public class StructuredConcurrencyBar implements Bar {
    @Override
    public DrinkOrder determineDrinkOrder(Guest guest) throws InterruptedException, ExecutionException {
        Waiter zoe = new Waiter("Zoe");
        Waiter elmo = new Waiter("Elmo");

        try (var scope = new StructuredTaskScope.ShutdownOnSuccess<DrinkOrder>()) {
            scope.fork(() -> zoe.getDrinkOrder(guest, BEER, WINE, JUICE));
            scope.fork(() -> elmo.getDrinkOrder(guest, COFFEE, TEA, COCKTAIL, DISTILLED));

            return scope.join().result(); // 1
        }
    }
}

In this example the waiter is responsible for getting a valid DrinkOrder object based on guest preference and the drinks supply at the bar. In the method Waiter.getDrinkOrder(Guest guest, DrinkCategory... categories), the waiter starts to list all available drinks in the drink categories that were passed to the method. Once a guest hears something they like, they respond and the waiter creates a drink order. When this happens, the getDrinkOrder(..) method returns a DrinkOrder object and the scope will shut down. This means that any unfinished subtasks (such as the one in which Elmo is still listing different kinds of tea) will be cancelled. The result() method at 1 will either return a valid DrinkOrder object, or throw an ExecutionException if one of the subtasks has failed.

Custom Shutdown Policies

Two shutdown policies are provided out-of-the-box, but it’s also possible to create your own by extending the class StructuredTaskScope and its protected handleComplete(..) method. That will allow you to have full control over when the scope will shut down and what results will be collected.

What’s Different From Java 22?

Compared to the preview version of this feature in Java 22, nothing was changed or added. JEP 480 simply exists to gather more feedback from users. Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, see JEP 480.

JEP 481: Scoped Values (Third Preview)

Scoped values enable the sharing of immutable data within and across threads. They are preferred to thread-local variables, especially when using large numbers of virtual threads.

The code examples that illustrate Scoped Values were taken from my conference talk “Java’s Concurrency Journey Continues! Exploring Structured Concurrency and Scoped Values”.

ThreadLocal

Since Java 1.2 we can make use of ThreadLocal variables, which confine a certain value to the thread that created it. Back then this was a simple way to achieve thread-safety, in some cases.

But thread-local variables also come with a few caveats. Every thread-local variable is mutable, making it hard to discern where shared state is updated and in what order. There’s also the risk of memory leaks, because unless you call remove() on the ThreadLocal the data is retained until it is garbage collected (which is only after the thread terminates). And finally, thread-local variables of a parent thread can be inherited by child threads, meaning that the child thread has to allocate storage for every thread-local variable previously written in the parent thread.

These drawbacks become more apparent now that virtual threads have been introduced, because millions of them could be active at the same time - each with their own thread-local variables - resulting in a significant memory footprint.

Scoped Values

Like a thread-local variable, a scoped value has multiple incarnations, one per thread. Unlike a thread-local variable, a scoped value is written once and is then immutable. It’s available only for a bounded period during execution of the thread.

To demonstrate this feature, we’ve added a scoped value to the StructuredConcurrencyBar class that you’re already familiar with:

public class StructuredConcurrencyBar implements Bar {
    private static final ScopedValue<Integer> drinkOrderId = ScopedValue.newInstance();

    @Override
    public DrinkOrder determineDrinkOrder(Guest guest) throws Exception {
        Waiter zoe = new Waiter("Zoe");
        Waiter elmo = new Waiter("Elmo");

        return ScopedValue.where(drinkOrderId, 1)
                .call(() -> {
                    try (var scope = new StructuredTaskScope.ShutdownOnSuccess<DrinkOrder>()) {
                        scope.fork(() -> zoe.getDrinkOrder(guest, BEER, WINE, JUICE));
                        scope.fork(() -> elmo.getDrinkOrder(guest, COFFEE, TEA, COCKTAIL, DISTILLED));

                        return scope.join().result();
                    }
                });
    }
}

We see that ScopedValue.where(...) is called, presenting a scoped value and the object to which it is to be bound. The invocation of call(...) binds the scoped value, providing an incarnation that is specific to the current thread, and then executes the lambda expression passed as argument. During the lifetime of call(...), the lambda expression - and any method called (in)directly from it - can read the scoped value via the value’s get() method. After the call(...) method finishes, the binding is destroyed.

Typical Use Cases

Scoped values will be useful in all places where currently thread-local variables are used for the purpose of one-way transmission of unchanging data.

What’s Different From Java 22?

The method ScopedValue.callWhere(key, value, operation) (which is a shorter way to write ScopedValue.where(key, value).call(operation);) can now throw a checked exception of a generic type. This means that you’re now able to catch that exception like this:

    try {
        var result = ScopedValue.callWhere(X, "hello", () -> bar());
    } catch (Exception e) {
        handleFailure(e);
    }
    // ...

Note that this JEP is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, see JEP 481.

HotSpot

Java 23 introduces a single change to HotSpot:

• ZGC: Generational Mode by Default

The HotSpot JVM is the runtime engine that is developed by Oracle. It translates Java bytecode into machine code for the host operating system’s processor architecture.

JEP 474: ZGC: Generational Mode by Default

The Z Garbage Collector (ZGC) is a scalable, low-latency garbage collector. It has been available for production use since Java 15 and has been designed to keep pause times consistent and short, even for very large heaps. It uses techniques like region-based memory management and compaction to achieve this.

Java 21 introduced an extension to ZGC that maintains separate generations for young and old objects, allowing ZGC to collect young objects (which tend to die young) more frequently. This will result in a significant performance gain for applications running with generational ZGC, without sacrificing any of the valuable properties that the Z garbage collector is already known for.

In Java 21, a command-line option was required to enable generational mode. Java 23 makes generational mode the default mode for ZGC, whereas non-generational mode has been deprecated. It will probably be removed in a future Java version.

What’s Different From Java 22?

To run your workload with Generational ZGC in Java 22, the following configuration was needed:

$ java -XX:+UseZGC -XX:+ZGenerational ...

In Java 23, this command-line option is no longer needed, it will use generational mode by default:

$ java -XX:+UseZGC ...

When you do still include it, a warning will be issued that the ZGenerational option is deprecated.

To revert back to non-generational ZGC, you would need to run:

$ java -XX:+UseZGC -XX:-ZGenerational ...

And you would get two warnings:

• The ZGenerational option is deprecated.
• Non-generational mode is deprecated.

More Information

For more information on this feature, see JEP 474.

Core Libraries

Java 23 also brings you 4 additions that are part of the core libraries:

• Class-File API (Second Preview)
• Vector API (Eighth Incubator)
• Stream Gatherers (Second Preview)
• Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

JEP 466: Class-File API (Second Preview)

Java’s ecosystem relies heavily on the ability to parse, generate and transform class files. Frameworks use on-the-fly bytecode transformation to transparently add functionality, for example. These frameworks typically bundle class-file libraries like ASM or Javassist to handle class file processing. However, they suffer from the fact that the six-month release cadence of the JDK causes the class-file format to evolve more quickly than before, meaning they might encounter class files that are newer than the class-file library that they bundle.

To solve this problem, JEP 466 proposes a standard class-file API that can produce class files that will always be up-to-date with the running JDK. This API will evolve together with the class-file format, enabling frameworks to rely solely on this API, rather than on the willingness of third-party developers to update and test their class-file libraries.

Elements, Builders and Transforms

The Class-File API, located in the java.lang.classfile package, consists of three main components:

Elements

Immutable descriptions of parts of a class file, such as instructions, attributes, fields, methods, or the entire file.

Builders

Corresponding builders for compound elements, offering specific building methods (e.g., ClassBuilder::withMethod) and serving as consumers of element types.

Transforms

Functions that take an element and a builder, determining if and how the element is transformed into other elements. This allows for flexible modification of class file elements.

Example and Comparison To ASM

Suppose we wish to generate the following method in a class file:

void fooBar(boolean z, int x) {
    if (z)
        foo(x);
    else
        bar(x);
}

With ASM we could generate the method like so:

ClassWriter classWriter = ...;
MethodVisitor mv = classWriter.visitMethod(0, "fooBar", "(ZI)V", null, null);
mv.visitCode();
mv.visitVarInsn(ILOAD, 1);
Label label1 = new Label();
mv.visitJumpInsn(IFEQ, label1);
mv.visitVarInsn(ALOAD, 0);
mv.visitVarInsn(ILOAD, 2);
mv.visitMethodInsn(INVOKEVIRTUAL, "Foo", "foo", "(I)V", false);
Label label2 = new Label();
mv.visitJumpInsn(GOTO, label2);
mv.visitLabel(label1);
mv.visitVarInsn(ALOAD, 0);
mv.visitVarInsn(ILOAD, 2);
mv.visitMethodInsn(INVOKEVIRTUAL, "Foo", "bar", "(I)V", false);
mv.visitLabel(label2);
mv.visitInsn(RETURN);
mv.visitEnd();

Unlike in ASM, where clients directly create a ClassWriter and then request a MethodVisitor, the Class-File API adopts a different approach. Here, instead of clients initiating a builder through a constructor or factory, they supply a lambda function that takes a builder as its parameter:

ClassBuilder classBuilder = ...;
classBuilder.withMethod("fooBar", MethodTypeDesc.of(CD_void, CD_boolean, CD_int), flags,
                        methodBuilder -> methodBuilder.withCode(codeBuilder -> {
    Label label1 = codeBuilder.newLabel();
    Label label2 = codeBuilder.newLabel();
    codeBuilder.iload(1)
        .ifeq(label1)
        .aload(0)
        .iload(2)
        .invokevirtual(ClassDesc.of("Foo"), "foo", MethodTypeDesc.of(CD_void, CD_int))
        .goto_(label2)
        .labelBinding(label1)
        .aload(0)
        .iload(2)
        .invokevirtual(ClassDesc.of("Foo"), "bar", MethodTypeDesc.of(CD_void, CD_int))
        .labelBinding(label2);
        .return_();
});

What’s Different From Java 22?

Some refinements were made based on experience and feedback from the first preview stage; these are the most important ones:

• The CodeBuilder class has been streamlined. This class has three kinds of factory methods for bytecode instructions: low-level factories, mid-level factories, and high-level builders for basic blocks. Based on feedback, mid-level methods that duplicated low-level methods or were infrequently used were removed, and the remaining mid-level methods were renamed to improve usability.
• The AttributeMapper instances in Attributes have been made accessible via static methods instead of static fields, to allow lazy initialization and reduce startup cost.
• Signature.TypeArg has been remodeled to be an algebraic data type, to ease access to the bound type when the TypeArg’s kind is bounded.
• Type-aware ClassReader::readEntryOrNull and ConstantPool::entryByIndex methods have been added, which throw ConstantPoolException instead of ClassCastException if the entry at the index is not of the desired type. This allows class-file processors to indicate that a constant pool entry-type mismatch is a class-file format problem instead of the processor’s problem.

Note that the Class-File API is in the preview stage, so you’ll need to add the --enable-preview flag to the command-line to take the feature for a spin.

More Information

For more information on this feature, including the minor refinements and more details on transforming class files, see JEP 466.

JEP 469: Vector API (Eighth Incubator)

The Vector API makes it possible to express vector computations that reliably compile at runtime to optimal vector instructions. This means that these computations will significantly outperform equivalent scalar computations on the supported CPU architectures (x64 and AArch64).

Vector Computations? Help Me Out Here!

A vector computation is a mathematical operation on one or more one-dimensional matrices of an arbitrary length. Think of a vector as an array with a dynamic length. Furthermore, the elements in the vector can be accessed in constant time via indices, just like with an array.

In the past, Java programmers could only program such computations at the assembly-code level. But now that modern CPUs support advanced SIMD features (Single Instruction, Multiple Data), it becomes more important to take advantage of the performance gains that SIMD instructions and multiple lanes operating in parallel can bring. The Vector API brings that possibility closer to the Java programmer.

Code Example

Here is a code example (taken from the JEP) that compares a simple scalar computation over elements of arrays with its equivalent using the Vector API:

void scalarComputation(float[] a, float[] b, float[] c) {
   for (int i = 0; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
   }
}

static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;

void vectorComputation(float[] a, float[] b, float[] c) {
    int i = 0;
    int upperBound = SPECIES.loopBound(a.length);
    for (; i < upperBound; i += SPECIES.length()) {
        // FloatVector va, vb, vc;
        var va = FloatVector.fromArray(SPECIES, a, i);
        var vb = FloatVector.fromArray(SPECIES, b, i);
        var vc = va.mul(va)
                   .add(vb.mul(vb))
                   .neg();
        vc.intoArray(c, i);
    }
    for (; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
    }
}

From the perspective of the Java developer, this is just another way of expressing scalar computations. It might come across as being more verbose, but on the other hand it can bring spectacular performance gains.

Typical Use Cases

The Vector API provides a way to write complex vector algorithms in Java that perform extremely well, such as vectorized hashCode implementations or specialized array comparisons. Numerous domains can benefit from this, including machine learning, linear algebra, encryption, text processing, finance, and code within the JDK itself.

What’s Different From Java 22?

Compared to the seventh incubator version of this feature in Java 22, nothing was changed or added. The Vector API will keep incubating until necessary features of Project Valhalla become available as preview features. When that happens, the Vector API will be adapted to use them, and it will be promoted from incubation to preview.

More Information

For more information on this feature, see JEP 469.

JEP 473: Stream Gatherers (Second Preview)

The Stream API has been around since Java 8 and it has definitely made its way into the heart of the typical Java developer. It enables a programming style that is both efficient and expressive. Recall that a stream pipeline consists of three parts: a source of elements, any number of intermediate operations, and a terminal operation. For example:

List<Guitar> guitars = List.of(
        new Guitar("Cordoba F7 Paco Flamenco", GuitarStyle.CLASSICAL),
        new Guitar("Taylor GS Mini-e Koa", GuitarStyle.WESTERN),
        new Guitar("Gibson Les Paul Standard '50s Heritage Cherry Sunburst", GuitarStyle.ELECTRIC),
        new Guitar("Fender Stratocaster", GuitarStyle.ELECTRIC));

long numberOfNonClassicalGuitars = guitars.stream() // source of elements
        .filter(g -> GuitarStyle.CLASSICAL != g.guitarStyle()) // intermediate operation
        .collect(Collectors.counting()); // terminal operation

The Stream API offers a relatively diverse but predetermined range of intermediate and terminal operations, including mapping, filtering, reduction, sorting, and more. Over the years, many new intermediate operations have been suggested for the Stream API. For example, it could be useful to introduce a distinctBy intermediate operation. A distinct operation does exist, tracking the elements it has already seen by using object equality. But what if we want distinct elements based on something else than object equality?

var singleGuitarPerStyle = guitars.stream()
                .distinctBy(Guitar::guitarStyle) // hypothetical
                .toList();

Over the years, many new intermediate operations have been suggested for the Stream API. Most of the suggestions that were made would make sense when considered in isolation, but adding all of them would make the (already large) Stream API more difficult to learn because its operations would be less discoverable. A better alternative would be to introduce the ability to define custom intermediate operations, analogous to how the Stream::collect terminal operation currently is extensible, enabling the output of a pipeline to be summarized in a variety of ways.

So that is why this JEP proposes an API for custom intermediate operations that allows developers to transform finite and infinite streams in their own preferred ways.

Gatherers

Stream::gather(Gatherer) is a new intermediate stream operation that processes stream elements by applying a user-defined gatherer. One could say it is the dual of Stream::collect(Collector), but for intermediate operations. Gatherers transform elements in different ways: one-to-one, one-to-many, many-to-one, or many-to-many. They can track previously seen elements, enable short-circuiting for infinite streams, and support parallel execution. For example, they may start by transforming one input element into one output element but switch to transforming one input element into two output elements based on a certain condition.

A gatherer implements the java.util.stream.Gatherer interface and is defined by four functions that work together:

initializer (optional)

Provides an object that maintains private state while processing stream elements.

integrator

Integrates a new element from the input stream.

combiner (optional)

Evaluates the gatherer in parallel when the input stream is marked as such.

finisher (optional)

Is invoked when there are no more input elements to consume.

When Stream::gather is called, it roughly performs the following steps: