Category: Java – Updates, How-Tos, and Tutorials

Java 26 has been in the so-called “Rampdown Phase One” since December 4, 2025, meaning no further JDK Enhancement Proposals (JEPs) will be included in the release. The feature set has therefore been finalized. Only bugs will be fixed and minor improvements made where necessary.

The target release date is March 17, 2026. You can download the current Early Access version here.

With 10 delivered JDK Enhancement Proposals (JEPs), Java 26 is one of the more manageable releases of recent years. Half of the JEPs are minor to medium-sized changes – such as warnings for mutating final fields and HTTP/3 support.

The other half are re-proposed previews – i.e., updates to features that have already been introduced but not yet finalized. Except for Lazy Constants (previously known as Stable Values), there were only minimal changes here.

For all JEPs and changes from the release notes, I use the original English terms as always.

Prepare to Make Final Mean Final – JEP 500

Most developers assume that a field we mark as final is immutable. In fact, we cannot simply assign a new value to a final field using an equals sign. However, so-called Deep Reflection allows us to bypass this restriction.

Here is a small example class to which we pass a value in the constructor, which is then stored in the final field value:

public class Box {
  private final Object value;

  public Box(Object value) {
    this.value = value;
  }

  @Override
  public String toString() {
    return "Box{value=" + value + "}";
  }
}Code language: Java (java)

The following code shows how easily the content of the final field can be changed – even from outside the object:

Box box = new Box("Rubic's Cube");

IO.println("box = " + box);

Field valueField = Box.class.getDeclaredField("value");
valueField.setAccessible(true);
valueField.set(box, "Magic Wand");

IO.println("box = " + box);Code language: Java (java)

Here we bypass both the encapsulation of the field via private and immutability via final. And this code can be executed from anywhere, for example, by third-party libraries that we don’t even know are on the classpath.

This problem was recognized years ago, and therefore, with Hidden Classes in Java 15 and Records in Java 16, Deep Reflection was not allowed from the outset.

In Java 16, “Strong Encapsulation” for JDK internals was also introduced. Since then, we have had to explicitly allow Deep Reflection across module boundaries with --add-opens. However, this only works for custom applications if they also use the module system.

To make Java more secure, the modification of final fields via Deep Reflection will be fundamentally prohibited in the future – even within a module.

Warnings in Java 26

In Java 26, JDK Enhancement Proposal 500 introduces warnings as a first step. The code shown above runs without issues in Java 25; in Java 26, it now displays the following warning:

WARNING: Final field value in class eu.happycoders.java26.jep500.Box has been mutated reflectively by class eu.happycoders.java26.jep500.FinalTest in unnamed module @3f99bd52
WARNING: Use --enable-final-field-mutation=ALL-UNNAMED to avoid a warning
WARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabledCode language: plaintext (plaintext)

The use of Deep Reflection can be explicitly allowed for specific modules via --enable-final-field-mutation=<Modulname> – thus preventing the warning.

In a future Java version, Deep Reflection will be forbidden by default – instead of a warning, an exception will be thrown, unless Deep Reflection is explicitly allowed via --enable-final-field-mutation.

The future behavior can already be enabled using the VM option --illegal-final-field-mutation. The option offers the following possibilities:

In a future Java version, deny will become the default setting, and allow will no longer be allowed. Then, Deep Reflection must be activated at the module level via --enable-final-field-mutation.

The guarantee that final fields are truly final not only protects against unexpected behavior but also improves application performance: If the JVM knows that a field cannot be changed, it can optimize access to it via Constant Folding – a type of inlining for constants.

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

In Java 24, Ahead-of-Time Class Loading & Linking was introduced – the ability to store the classes required by an application in an architecture-specific binary format in a so-called Ahead-of-Time cache – and to load them from there to significantly accelerate application startup (by up to 42% in tests).

Previously, classes were stored in the cache exactly as the Garbage Collector places them on the heap, including headers and references to other objects (e.g., from Class objects to strings). This has the advantage that the Ahead-of-Time cache file can be mapped directly from the file system to the heap – and this happens with virtually no time loss if the Ahead-of-Time cache file is in the file system cache.

However, the binary representation of both object headers and references can differ from Garbage Collector to Garbage Collector or depending on VM options:

• With Compressed OOPs (default for heaps up to 32 GB), references are 32 bits long.
• Without Compressed OOPs (with a heap larger than 32 GB or with the VM option -XX:-UseCompressedOOPs), they are 64 bits long.
• ZGC uses some bits of the references for metadata.
• By activating Compact Object Headers (-XX:+UseCompactObjectHeaders) or deactivating Compressed Class Pointers (deprecated since Java 25), the binary format of the header changes.

Therefore, an Ahead-of-Time cache created with G1, Serial GC, or Parallel GC could not previously be read by applications using ZGC – and vice versa. Similarly, a cache created with Compressed OOPs or Compact Object Headers enabled could not be read by an application where Compressed OOPs or Compact Object Headers were disabled – and vice versa.

GC-Independent Ahead-of-Time Cache

To use the Ahead-of-Time cache more flexibly, starting with Java 26, we can create a GC-independent Ahead-of-Time cache. In this approach, objects in the cache file are referenced by their index within the cache. The cache file can no longer be directly mapped to the heap. Instead, objects are gradually read from the file and then stored on the heap in the GC-specific format and correctly linked there – or, in other words: they are streamed from the cache file to the heap.

The GC-independent format (also called “Streamable Objects”) is used if, during the training run…

• ZGC was used – or
• Compressed OOPs were deactivated with -XX:-CompressedOops – or
• the heap was larger than 32 GB – or
• the VM option -XX:+AOTStreamableObjects was specified.

If, on the other hand, an application was started with G1, Serial GC, or Parallel GC and a heap of a maximum of 32 GB, the previous, GC-specific format is used.

HTTP/3 for the HTTP Client API – JEP 517

The next feature is already fully explained by the heading: The HttpClient API supports version 3 of the HTTP protocol (introduced in 2022) starting with Java 26.

With the HttpClient API, you could, for example, load the content of my homepage and store it in a string as follows:

HttpClient client = HttpClient.newHttpClient();

HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://www.janice.happycoders.eu/"))
    .build();

HttpResponse<String> response =
    client.send(request, BodyHandlers.ofString());

String responseBody = response.body();Code language: Java (java)

By default, HTTP/2 was used here – and that doesn’t change with Java 26, as only about one-third of all websites currently support HTTP/3.

However, you can now explicitly enable HTTP/3 as follows:

HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://www.janice.happycoders.eu/"))
    .version(HttpClient.Version.HTTP_3) // ← Try to use HTTP/3
    .build();Code language: Java (java)

Thus, an attempt is made to communicate with the server via HTTP/3. If the server does not support HTTP/3, it will transparently switch to HTTP/2.

G1 GC: Improve Throughput by Reducing Synchronization – JEP 522

G1 is the default Garbage Collector of the JVM – it offers a balanced ratio of high throughput and low latencies (in contrast, Serial GC and Parallel GC are designed for the highest possible throughput, and ZGC and Shenandoah for the lowest possible latencies).

When the Garbage Collector moves an object, it must also adjust all references to that object. Scanning the entire heap for this would be very inefficient. Therefore, G1 only scans objects within a region (as a reminder: G1 divides the heap into approximately 2,048 regions) – references from one region to another, however, are stored in a separate, efficient data structure called Card Table. G1 can search this particularly quickly.

How does G1 know that the application code has set a reference from one object to another, which also needs to be stored in the Card Table? Through so-called Write Barriers: short pieces of machine code that G1 weaves into the code when an application starts.

To ensure that scanning the Card Table after moving an object is as fast as possible, G1 continuously optimizes the Card Table in the background. Since G1 runs in parallel with the application, access to the Card Table by application threads via Write Barriers and access by the optimization thread must be synchronized. This, in turn, represents a significant overhead.

Reducing Synchronization Overhead in Java 26

Therefore, G1 is optimized in Java 26 as follows:

A second Card Table is introduced. While the application threads access one of these two Card Tables, the optimization thread optimizes the other. As soon as a Card Table has been modified so heavily by the application threads that the time required to scan it exceeds a certain limit, the Card Tables are swapped. The application thread then accesses the previously optimized Card Table, while the optimization thread re-optimizes the Card Table that has become cumbersome.

The optimization thread therefore does not need to be synchronized with the concurrently running application. The reduced synchronization overhead can lead to an increase in overall throughput of 5 to 15%. The costs for this are minimal: a Card Table occupies 0.2% of the heap – accordingly, with a constant heap size, only 0.2% more native memory is required.

This optimization takes effect after an upgrade to Java 26 without any code changes or VM parameter adjustments.

Re-proposed Preview and Incubator Features

None of the five features that were in preview or incubator status in Java 25 were finalized in Java 26. All five features were re-proposed with minor or major changes. The following sections describe the features with a focus on the changes compared to Java 25.

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

PEM stands for Privacy-Enhanced Mail and represents an encoding scheme for cryptographic objects. You have certainly seen PEM-encoded objects before – such as the following PEM-encoded cryptographic certificate:

-----BEGIN CERTIFICATE-----
MIIDtzCCAz2gAwIBAgISBUCeYELtjMmr4FAIqHapebbFMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
. . .
DBeMde1YpWNXpF9+B/OMKgn7RgXRj5b2QpBCnFsP92T4cK/Nn+xFIjYCMCCx4E79
toSQBlYnNHv0eXnWkI8TmXsU/A6rU4Gxdr9GbGixgRJvkw0C6zjL/lH2Vg==
-----END CERTIFICATE-----Code language: plaintext (plaintext)

Writing or reading PEM-encoded objects in Java was previously extremely complicated and required over a dozen lines of code. The following example shows what you had to write to read a PEM-encoded private key in Java:

String encryptedPrivateKeyPemEncoded = . . .
String passphrase = . . .

String encryptedPrivateKeyBase64Encoded = encryptedPrivateKeyPemEncoded
    .replace("-----BEGIN ENCRYPTED PRIVATE KEY-----", "")
    .replace("-----END ENCRYPTED PRIVATE KEY-----", "")
    .replaceAll("[\\r\\n]", "");

Base64.Decoder decoder = Base64.getDecoder();
byte[] encryptedPrivateKeyBytes = decoder.decode(encryptedPrivateKeyBase64Encoded);
EncryptedPrivateKeyInfo encryptedPrivateKeyInfo =
    new EncryptedPrivateKeyInfo(encryptedPrivateKeyBytes);

String algorithmName = encryptedPrivateKeyInfo.getAlgName();
SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance(algorithmName);

PBEKeySpec pbeKeySpec = new PBEKeySpec(passphrase.toCharArray());
Key pbeKey = secretKeyFactory.generateSecret(pbeKeySpec);

Cipher cipher = Cipher.getInstance(algorithmName);
AlgorithmParameters algParams = encryptedPrivateKeyInfo.getAlgParameters();
cipher.init(Cipher.DECRYPT_MODE, pbeKey, algParams);

KeyFactory rsaKeyFactory = KeyFactory.getInstance("RSA");
KeySpec keySpec = encryptedPrivateKeyInfo.getKeySpec(cipher);
PrivateKey privateKey = rsaKeyFactory.generatePrivate(keySpec);Code language: Java (java)

In Java 25, a dedicated PEM API was introduced as a preview feature, intended to significantly simplify handling PEM-encoded objects. Reading the encrypted private key is thus possible with just a few lines of code (or just one, if you write everything on a single line):

PrivateKey privateKey = PEMDecoder.of()
    .withDecryption(passphrase.toCharArray())
    .decode(encryptedPrivateKeyPemEncoded, PrivateKey.class);Code language: Java (java)

In addition to the PEMDecoder shown above, there is a corresponding PEMEncoder with a encode() method.

In Java 26, the basic functionality of this API remains the same – only a few details have been changed and the scope of functions has been slightly increased:

• Some classes and methods have been renamed, and some methods have been added (the simple example above was not affected by these changes).
• Some exceptions have been adjusted.
• In addition to the existing cryptographic objects, key pairs and PKCS#8-encoded keys can now also be encoded and decoded.

More details on the new API and these changes can be found in JDK Enhancement Proposal 524.

Structured Concurrency (Sixth Preview) – JEP 525

Structured Concurrency is already in its sixth preview round. If you are already familiar with the API and just want to know what has changed in Java 26, you can jump to the section Structured Concurrency – Changes in Java 26.

What is Structured Concurrency?

Structured Concurrency means – in contrast to Unstructured Concurrency and based on Structured Programming – that the execution paths created when starting concurrent threads converge at a single point in the code – and that it is guaranteed that no orphaned threads are still running at that point.

The following graphic illustrates this. It also shows that “scopes” (= the areas in which concurrent tasks are executed) created by Structured Concurrency can be nested:

This was previously possible – to a limited extent – with a ExecutorService and the invocation of close() or shutdown() and awaitTermination(). However, the Java API for Structured Concurrency, , offers additional ways to prematurely terminate a scope upon the occurrence of certain events and cancel all still-running tasks. With a ExecutorService, this was only possible with extremely complex and thus error-prone orchestration.

StructuredTaskScope API

The following example shows how multiple subtasks can be started in parallel with the StructuredTaskScope API, and then the result of all subtasks is awaited. Should one of the subtasks fail, the still-running subtasks are canceled, and scope.join() throws the exception that occurred in the failed subtask.

Invoice createInvoice(int orderId, int customerId, String language)
    throws InterruptedException {
  try (var scope = StructuredTaskScope.open()) {
    var orderTask    = scope.fork(() -> orderService.getOrder(orderId));
    var customerTask = scope.fork(() -> customerService.getCustomer(customerId));
    var templateTask = scope.fork(() -> templateService.getTemplate(language));

    scope.join();

    var order    = orderTask.get();
    var customer = customerTask.get();
    var template = templateTask.get();

    return Invoice.generate(order, customer, template);
  }
}Code language: Java (java)

The following example shows another strategy (enabled by Joiner.anySuccessfulOrThrow()): Here, only the result of one of the subtasks is needed – and as soon as it is available, the other subtasks are canceled:

AddressVerificationResponse verifyAddress(Address address) throws InterruptedException {
  try (var scope = StructuredTaskScope.open(
      Joiner.<AddressVerificationResponse>anySuccessfulOrThrow())) {

    scope.fork(() -> verificationService.verifyViaServiceA(address));
    scope.fork(() -> verificationService.verifyViaServiceB(address));
    scope.fork(() -> verificationService.verifyViaServiceC(address));

    return scope.join();
  }
}Code language: Java (java)

The Joiner interface used here provides further strategies. You can find out what these are and how you can implement your own strategies in the main article on Structured Concurrency in Java.

Structured Concurrency – Changes in Java 26

Structured Concurrency was first introduced in Java 21. In Java 25, the API was fundamentally revised (keyword: “Composition over Inheritance”). In Java 26, the following extensions and adjustments were made through JDK Enhancement Proposal 525:

• The Joiner interface has received an additional method onTimeout(), in addition to onFork() and onComplete(). This method is called by StructuredTaskScope.join() in case of a timeout and throws a TimeoutException by default. However, it can be overridden in a custom Joiner to handle timeouts alternatively – e.g., to return a specific value.
• The Joiner created by Joiner.allSuccessfulOrThrow() no longer returns a stream of subtasks (which are all successful anyway), but a list of the results of the subtasks.
• The Joiner created by Joiner.allUntil(...) returns a list of subtasks instead of a stream of subtasks.
• The method Joiner.anySuccessfulResultOrThrow() was renamed to anySuccessfulOrThrow() (the word Result was removed, as it is not used in the other Joiner factory methods either).
• There is an overloaded StructuredTaskScope.open(...) method that allows customizing the configuration of a joiner. In this method, the type for the configuration parameter was changed from Function<Configuration, Configuration> to UnaryOperator<Configuration> (which is ultimately a Function<Configuration, Configuration> again).

Code written with Java 25 therefore requires only minor (or no) adjustments to run on Java 26.

Lazy Constants (Second Preview) – JEP 526

Lazy Constants were introduced in Java 25 as Stable Values. If you are already familiar with Stable Values and are only interested in the changes in Java 26, you can jump to the section Lazy Constants – Changes in Java 26.

What problem do we want to solve?

Constants – i.e., immutable values – have many advantages: They make the code simpler and safer, as they can only be in one state and can be safely accessed from multiple threads. In addition, they enable performance optimizations by the JVM, e.g., through Constant Folding (already mentioned above for final fields).

Until now, constants could only be defined by final fields:

• final static fields, which are initialized when a class is loaded – or
• final instance fields, which are initialized when an object is created.

If you want to initialize an immutable value only when needed, e.g., because the initialization is expensive, you have to use the concept of “Lazy Initialization”. To make lazy initialization thread-safe in Java, we previously had to resort to either the Double-Checked-Locking-Idiom or the Initialization-on-Demand-Holder-Idiom. Anyone who has done this before knows that errors can easily creep in.

Lazy Constants API

In Java 25, the Stable Values API was introduced to simplify Lazy Initialization. After extensive feedback, the API in Java 26 was greatly simplified by JDK Enhancement Proposal 526 and renamed to Lazy Constants.

The following example shows how we define a LazyConstant that initializes a Settings object by loading it from a database only upon its first access:

private final LazyConstant<Settings> settings =
    LazyConstant.of(this::loadSettingsFromDatabase);

public Locale getLocale() {
  return settings.get().getLocale(); // ⟵ Here we access the lazy constant
}Code language: Java (java)

Only on the first call to settings.get() will the loadSettingsFromDatabase() method be invoked. The value is then stored in the LazyConstant object, and subsequent calls to settings.get() will return this stored value. Thread safety is also guaranteed: Should settings.get() be called simultaneously from multiple threads, loadSettingsFromDatabase() will still be called at most once.

Once the LazyConstant is initialized, it is interpreted as immutable by the JVM, and access to it is optimized through Constant Folding.

Lazy Lists

In addition to individual Lazy Constants, we can also define Lazy Lists – lists where each element is a Lazy Constant. The following example shows a simple Lazy List in which each field is lazily initialized with the square root of the field index:

private final List<Double> squareRoots = List.ofLazy(100, Math::sqrt);Code language: Java (java)

Here too, initialization only occurs on first access – and separately for each element of the list, e.g., during direct access with get(int index) – or when iterating over the list. And here too, initialization is thread-safe, and after initialization, the values are treated and optimized by the JVM like constants.

Lazy Maps

Maps can also be lazily initialized in the future. The following example shows a Lazy Map where Locales are mapped to ResourceBundles:

Set<Locale> supportedLocales = getSupportedLocales();
Map<Locale, ResourceBundle> resourceBundles =
    Map.ofLazy(supportedLocales, this::loadResourceBundle);Code language: Java (java)

On the first access to a map element for a specific Locale, the corresponding ResourceBundle is loaded via loadResourceBundle() and then stored in the map as a constant. Just like Lazy Constants and Lazy Lists, Lazy Maps are also thread-safe.

Lazy Constants – Changes in Java 26

In addition to the obvious change – the renaming to Lazy Constants – the following simplifications were made in Java 26:

• Low-level methods such as orElseSet(), setOrThrow(), and trySet() were removed, as they made the API unnecessarily complicated.
• Lazy Lists and Lazy Maps were previously created via StableValue.list(...) and StableValue.map(...). These factory methods were moved to the List and Map interfaces, respectively.
• The Function and IntFunction implementations created via StableValue.function(...) and StableValue.intFunction(...), respectively, were removed without replacement, as they offered no added value compared to Lazy Lists and Lazy Maps.
• For performance reasons, Lazy Constants, Lazy Lists, and Lazy Maps may no longer contain null values. If the computation function returns null, an NullPointerException is thrown.

So, if you have already relied on Stable Values in Java 25, extensive refactoring will be required.

Vector API (Eleventh Incubator) – JEP 529

And now, for the eleventh time, we come to the Vector API.

With the Vector API, mathematical vector operations can be calculated particularly efficiently using the vector instruction sets of modern CPUs (such as SSE and AVX) – e.g., a vector addition like the following:

As Java code, this operation would be implemented as follows, where a and b are the input vectors and c is the output vector:

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

void addVectors(float[] a, float[] b, float[] c) {
  int i = 0;
  int upperBound = SPECIES.loopBound(a.length);
  for (; i < upperBound; i += SPECIES.length()) {
    var va = FloatVector.fromArray(SPECIES, a, i);
    var vb = FloatVector.fromArray(SPECIES, b, i);
    var vc = va.add(vb);
    vc.intoArray(c, i);
  }
  for (; i < a.length; i++) {
    c[i] = a[i] + b[i];
  }
}Code language: Java (java)

Currently, quite a lot of boilerplate is still necessary for such a simple operation:

• Via SPECIES.length(), it is queried how many vector elements can be processed simultaneously in one CPU cycle.
• SPECIES.loopBound(...) calculates into how many complete sub-vectors of this length the output vector can be split.
• All sub-vectors are added via the first loop.
• If the length of the output vector is not a multiple of the sub-vector length, a remainder remains. Its elements are individually added via the second loop.

I am curious if the API will be further simplified after it reaches the preview stage.

However, we still have to be patient until the first JEP from Project Valhalla – JEP 401: Value Classes and Objects – reaches the preview stage. This is because the Vector class is intended to be a Value Class from the start – i.e., a class whose objects will manage without identity.

When will it be ready? Brian Goetz, Language Architect at Oracle, has consistently answered the question about Project Valhalla’s release date for years with: “It’s ready when it’s ready” – he has not yet been persuaded to give a more concrete statement. On October 10, 2025, the Java community was finally provided with a first Early-Access Build of Project Valhalla.

The eleventh incubator version of the Vector API is described in JDK Enhancement Proposal 529: There are no substantial changes compared to the previous version.

You can find more examples and details in the main article about lazy constants.

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

Pattern Matching with primitive types was first introduced in Java 23 as a preview feature. Since then, there have been no fundamental changes. If you are already familiar with the feature and are interested in the minor refinements in Java 26, feel free to jump to the section Primitive Types in Patterns – Changes in Java 26.

Pattern Matching and switch with Primitive Types – Current Status

Pattern Matching has so far been limited to reference types, for example, as follows:

Object obj = . . .
switch (obj) {
  case String s when s.length() >= 5 -> IO.println(s.toUpperCase());
  case Integer i                     -> IO.println(i * i);
  case null, default                 -> IO.println(obj);
}Code language: Java (java)

A switch over primitive types is possible – but only with byte, short, char and int – and in the case-labels, only constants are allowed:

int code = . . .
switch (code) {
  case 200 -> IO.println("OK");
  case 404 -> IO.println("Not Found");
}Code language: Java (java)

Pattern Matching and switch with Primitive Types – What will change?

In the future, all primitive types should be allowed in switch, including long, double, float, and even boolean. And patterns should also be allowed in the case labels. This would allow us to check, for example, a int value against specific number ranges:

int code = . . .
switch (code) {
  case int i when i >= 100 && i < 200 -> IO.println("information");
  case int i when i >= 200 && i < 300 -> IO.println("success");
  case int i when i >= 300 && i < 400 -> IO.println("redirection");
  case int i when i >= 400 && i < 500 -> IO.println("client error");
  case int i when i >= 500 && i < 600 -> IO.println("server error");
  default -> throw new IllegalArgumentException();
}Code language: Java (java)

Patterns with reference types also match derived types, e.g., a case Number n would also match an object of type Integer. With primitive types, there is no inheritance – therefore, the JDK developers have come up with something different here:

In the future, we can check with switch (and similarly with instanceof) whether the value of a primitive variable can be represented by another primitive type without loss of precision:

double value = . . .
switch (value) {
  case byte   b -> IO.println(value + " instanceof byte:   " + b);
  case short  s -> IO.println(value + " instanceof short:  " + s);
  case char   c -> IO.println(value + " instanceof char:   " + c);
  case int    i -> IO.println(value + " instanceof int:    " + i);
  case long   l -> IO.println(value + " instanceof long:   " + l);
  case float  f -> IO.println(value + " instanceof float:  " + f);
  case double d -> IO.println(value + " instanceof double: " + d);
}Code language: Java (java)

If value here were, for example, 42, then the pattern byte b would match, since 42 can also be stored in a byte. If value were, for example, 50,000, then the pattern char c would match. For 65,000, int i would match, for 0.5 float f, and for 0.7, only double d.

The dominance principle also applies to primitive types: The order of the case labels in the previous example must not be changed, as individual case labels would then no longer be reachable. For example, the pattern int i should not appear before byte b, as every possible byte would already match int i.

Primitive Types in Patterns – Changes in Java 26

Through JDK Enhancement Proposal 530, the dominance check was mainly improved in Java 26. The following code, for example, can still be compiled without errors with Java 25:

int i1 = . . .
switch (i1) {
  case float f -> {}
  case 16_777_216 -> {}
  default -> {}
}

int i2 = . . .
switch (i2) {
  case int _ -> {}
  case float _ -> {}
}

byte b = . . .
switch (b) {
  case short s -> {}
  case 42 -> {}
}Code language: Java (java)

In Java 26, however, all three switch statements are met with compiler errors:

• In the first switch, the constant 16,777,216 can never match, since this number can also be precisely represented by a float, and thus the constant is dominated by the pattern float f.
• In the second switch, the pattern float f can never match, since every value that i2 can take is already matched by the pattern int _.
• In the third switch, the constant 42 can never match, since 42 can also be stored in a short, and thus the constant is dominated by the pattern short s.

Apart from the improved dominance check, there are no other changes in Java 26.

Deprecations and Deletions

In Java 26, the Applet API and the Thread.stop() method were removed. You can find details in the following two sections.

Remove the Applet API – JEP 504

The Applet API and the Security Manager, which was responsible for securing applets, were marked as deprecated in Java 9 in 2017, as applets were no longer supported by any modern web browser at that time. In Java 17, the Applet API and Security Manager were marked as deprecated for removal.

The Security Manager was disabled in Java 24.

In Java 26, the Applet API – i.e., all classes in the java.applet package as well as some others, such as java.beans.AppletInitializer and javax.swing.JApplet – has now been completely removed via JDK Enhancement Proposal 504.

Thread.stop is removed

Thread.stop() It was already marked as deprecated in Java 1.2 – in December 1998 – because it could lead to inconsistent states and unpredictable behavior. In Java 18, it was marked as deprecated for removal, and since Java 20, it throws an UnsupportedOperationException.

In Java 26 – more than 27 years after being marked as deprecated – the method is now completely removed.

(There is no JEP for this change; it is registered in the bug tracker under JDK-8368226.)

Other Changes in Java 26

In this section, you will find a selection of minor changes from the release notes for which no JDK Enhancement Proposals were written.

Add Dark Theme to API Documentation

This feature is quickly explained: in Java 26, the Javadoc documentation offers a dark mode. You can already try it out in the Early-Access documentation of 26 by clicking on the sun or moon icon in the menu bar.

Here’s an impression of the new mode:

(There is no JEP for this change; it is registered in the bug tracker under JDK-8342705.)

New ofFileChannel Method in java.net.http.HttpRequest.BodyPublishers

To send a file with the HttpClient API (available since Java 11), it previously had to be completely loaded into RAM and passed as a byte array to the HttpRequest:

byte[] fileContent = Files.readAllBytes(Path.of("test.bin"));

try (HttpClient client = HttpClient.newHttpClient()) {
  HttpRequest request =
      HttpRequest.newBuilder()
          .uri(URI.create("https://www.example.com/upload"))
          .POST(BodyPublishers.ofByteArray(fileContent))
          .build();

  HttpResponse<Void> response =
      client.send(request, HttpResponse.BodyHandlers.discarding());
}Code language: Java (java)

Starting with Java 26, a file (or part of it) can also be streamed via FileChannel to the HttpRequest and thus no longer needs to be fully available in memory beforehand. This is particularly helpful for very large files:

try (FileChannel fileChannel = 
        FileChannel.open(Path.of("test.bin"), StandardOpenOption.READ);
    HttpClient client = HttpClient.newHttpClient()) {

  HttpRequest request =
      HttpRequest.newBuilder()
          .uri(URI.create("https://www.example.com/upload"))
          .POST(BodyPublishers.ofFileChannel(fileChannel, 0, fileChannel.size()))
          .build();

  HttpResponse<Void> response =
      client.send(request, HttpResponse.BodyHandlers.discarding());
}Code language: Java (java)

(There is no JEP for this change; it is registered in the bug tracker under JDK-8329829.)

Default initial heap size is trimmed down

If neither -Xms nor -XX:InitialRAMPercentage is used to specify a minimum heap size when starting a Java application, the heap is set by default to 1/64 (= 1.5625%) of the physical RAM. Today, computers have significantly more RAM than twenty years ago, so many applications are equipped with an unnecessarily large heap. On my 64 GB laptop, for example, even a Hello World application is started with a 1 GB heap.

Besides the unnecessarily occupied RAM, this can also noticeably delay the start of an application, because the Garbage Collector has to create initial data structures for the heap, which scale with the heap size.

In Java 26, the initial heap size is changed by default to 0.2%, i.e., 1/500 of the physical RAM. On my 64 GB laptop, this is still a sufficient 128 MB for many small applications.

(There is no JEP for this change; it is registered in the bug tracker under JDK-8348278.)

Virtual threads now unmount when waiting for another thread to execute a class initializer

Under certain circumstances, virtual threads are “pinned” to their carrier thread, meaning that if the virtual thread blocks, it cannot be unmounted from its carrier thread (the operating system thread on which the virtual thread is executed). Thus, the carrier thread is also blocked and cannot execute another virtual thread.

Already in Java 24, the serious pinning issue within synchronized blocks was resolved.

Before Java 26, a virtual thread was also pinned if it tried to initialize a class that was currently being initialized by another thread. This no longer happens either.

(There is no JEP for this change; it is registered in the bug tracker under JDK-8369238.)

Support for Unicode 17.0

Java 26 increases Unicode support to version 17.0.

Why is this relevant? All character-processing classes such as String and Character must be able to process the characters and code blocks introduced in the new Unicode version.

(For this change, there is no JEP; it is registered in the bug tracker under JDK-8346944.)

Complete List of All Changes in Java 26

In this article, I have presented all JDK Enhancement Proposals that were delivered with Java 26, as well as a selection of changes from the release notes. You can find the complete list of all changes in the Java 26 Release Notes.

Conclusion

Compared to the last two Java versions, the changes in Java 26 are quite manageable:

• Mutating final fields with deep reflection now issues a warning – in the future, an exception will be thrown.
• The Ahead-of-Time Class Loading & Linking introduced in Java 24 now works with any garbage collector – no longer just with G1.
• HttpClient now supports HTTP/3.
• The G1 Garbage Collector has been optimized, leading to an increase in throughput.
• The Applet API and Thread.stop() have been removed.
• Stable Values have been renamed to Lazy Constants – and the API has been radically simplified.
• For the remaining features currently in preview, minor improvements have been made.

As always, various other changes round off the release. You can download the current Java 26 Early-Access Release here.

Which of the changes do you find most exciting? Share your opinion in the comments!

You probably know this: A new Java version is just around the corner – and while one or two team members are enthusiastic, the rest remain rather reserved or even block it. Even in management, enthusiasm is often limited when it comes to modernization, upgrades or investments in developer skills. After all, everything works somehow – and “Never change a running system” is a proven motto.

But once you’ve experienced how much more fun modern Java features make in everyday life, how much they speed up development, make code clearer and noticeably conserve resources, you won’t want to miss these advantages. The problem: To get modernization going, you need everyone on board – your team and the decision-makers.

In this article, you’ll learn how to convince both sides – with the right arguments, practical examples and concrete tips from everyday project work. Whether you’re passionate about an upgrade yourself or want to take your team with you as a manager: Here you’ll learn how modernization succeeds – and everyone wins.

Why It’s Often Difficult to get Everyone on Board with Java Modernization

Although modern Java versions bring numerous advantages – faster development, better readable code, more efficient use of resources – the path to modernization in many teams is not without obstacles. A field of tension often arises between developers who are enthusiastic about new language features such as Records, Pattern Matching or Virtual Threads, and colleagues who hesitate or are fundamentally skeptical of change.

On the other hand, there is management: Investments in upgrades, training or modernization measures must be justified in a comprehensible manner. The central question is usually: How great is the benefit in relation to the effort? Without clear answers – such as falling cloud costs, shorter release cycles or higher developer productivity – there is also a lack of willingness to invest, and modernization projects are put on the back burner.

Typical patterns that I see again and again in projects:

• Some team members are driving new features and improvements, but are met with reluctance or uncertainty in the rest of the team.
• The management level remains cautious as long as the existing code works and no critical incidents occur.
• There is uncertainty as to whether modern features are really stable – or change the existing code base too much.
• More urgent projects and day-to-day business repeatedly push modernization out of focus.

The consequence:

Innovation potentials remain unused, technical debts grow, and the concrete advantages of modern Java versions remain theory. This affects not only technical aspects – but also the motivation and further development of the team.

In the next sections, I’ll show you how to break through this dynamic: with arguments that resonate with the team, and with a language that convinces decision-makers – so that modernization is understood and supported as a joint project.

The Dynamics in the Team: What Slows down, What Motivates?

Every modernization project brings movement into the team – in the best case motivation, in the worst case uncertainty or even resistance. This dynamic is quite normal, because technical changes affect not only the code, but also established routines, ways of thinking and sometimes even the self-image as a developer.

What slows you down?

• Fear of extra effort: New language features mean training. Anyone who is already under time pressure fears additional stress – especially when deadlines are looming.
• Unclear benefits: If it is not visible how new features specifically affect your own project, the motivation remains low. Theory alone rarely convinces.
• Stability and security: Many developers rely on proven solutions. “What we know works” – this thinking is understandable, but risky in the long run.
• Heterogeneous levels of knowledge: There is often a wide range in the team: While some are already experimenting with the new features, others have remained with Java 8.
• Complexity of the code base: Especially when the existing code has grown historically and is difficult to understand, people shy away from changes – for fear of breaking something.

What motivates?

• Visible improvements: If modern features make the code leaner, reduce sources of errors or make tasks more efficient, interest grows quickly.
• Joint learning: Exchange within the team – for example through coding sessions or internal dojos – creates a positive learning culture and reduces fears.
• Quick wins: Even small modernizations with a measurable effect, e.g. reduced boilerplate or better readable code, often have a more convincing effect than any PowerPoint presentation.
• Recognition and further development: Anyone who contributes new things and implements them successfully strengthens their own role in the team – and promotes their own development.
• Clear benefits in everyday life: Modern Java features ensure a more understandable syntax and help to express intentions in the code more precisely – the code becomes easier to read and maintain for everyone.

Conclusion:

The motivation for modernization does not arise from regulations – but from tangible improvements and a common understanding. The better you address uncertainties in the team and make concrete advantages visible, the easier it will be to get everyone on board.

In the next step, we’ll take a look at how you can specifically get your team excited about modern Java versions – and which arguments work best.

Convincing your Team: how to Make Them Want Modern Java Versions

If there is skepticism in the team or the benefits of new Java versions are not yet tangible, it takes more than an abstract feature list. It is crucial that the advantages can be experienced in your own everyday life – and that no one feels overwhelmed or left alone.

Which arguments are really convincing?

• Less boilerplate, more clarity: Modern features such as Records, Pattern Matching or Switch Expressions help to significantly reduce redundant code. This makes applications leaner, more understandable – and saves time in development, reviews and maintenance.
• Express intention more precisely – with modern syntax: New language tools make it possible to map complex business logic more clearly. The code becomes more self-explanatory, less error-prone and still easy to understand months later – for yourself and for your colleagues.
• Performance and resource consumption: New Java versions bring continuous optimizations in execution – for example through modern garbage collectors or improvements in the hotspot compiler. The result: better performance without changes to the code.
• Asynchronous logic – without reactive complexity: Virtual threads enable a simple, imperative structure – with simultaneous scalability. Instead of complex reactive frameworks, classic code can often be used, which is more readable and maintainable.
• Motivation and further development: Current tools and language features bring a breath of fresh air into everyday development. It’s simply more fun to develop yourself further with current techniques – this strengthens motivation, competence and employer attractiveness.
• Quick wins: Even small changes – such as a first refactoring to records or a more elegant pattern matching – show how clarity and maintainability can be improved. Such quick wins are often more convincing than any theoretical presentation.

How to get your team on board:

• Start with realistic dry runs: Even if the project is (still) running on an older Java version, you can show in a separate branch how a piece of legacy code can be improved with modern language tools – initially without interfering with CI/CD or deployment.
• Use brown bag sessions: Informal short formats during the lunch break are perfect for sharing knowledge in a relaxed and pressure-free way.
• Create space for questions and exchange: Not everyone gets through immediately. Encourage them to ask questions openly and express uncertainties – for example in team meetings, internal forums or Slack channels.
• Focus on joint learning: Organize small coding sessions or dojos in which the team tries out new features together. This often leads to new ideas, and enthusiasm spills over to others.
• Actively involve skeptics: Encourage critical voices to formulate their concerns. Often a convincing example is enough to turn doubt into interest.
• Make progress visible: Record successes – for example with a small “Hall of Fame” for particularly successful code modernizations. Visible successes motivate – and invite imitation.

Conclusion:

Your team not only needs to know modern Java versions – it needs to feel their value. If you show how new language features noticeably improve everyday life, motivation, curiosity and willingness to learn arise all by themselves. The rest is a process – but one that is worthwhile.

The next chapter is about how to convince management – with arguments that translate technology into business benefits.

Inspiring Management: Translating Technology into Business Benefits

Even the most motivated development team reaches its limits when support from management is lacking. Investments in modernization, training or new tools must assert themselves against other priorities. That’s why it’s crucial not only to justify technical innovations technically – but to show their concrete benefits for the business.

What convinces decision-makers?

• Measurable results: Show how modernization affects concrete KPIs – for example through shorter release cycles, fewer failures or higher productivity in the team. Before-and-after comparisons from pilot projects or simple time/cost estimates are often particularly convincing.
• Reduced costs: Modern Java versions can significantly reduce resource requirements through targeted JVM optimizations and improved garbage collectors. Less CPU load, lower memory consumption and faster start-up times lead directly to lower cloud costs.
• Competitive advantages: An up-to-date technology stack not only increases the speed of innovation, but also makes the company more attractive to new talent. Those who use modern tools can develop new features faster and react more flexibly to market changes.
• Future security: Regular updates and modern language elements reduce technical ballast. This reduces the risk of security vulnerabilities and compliance problems. Maintenance becomes more predictable – and cheaper in the long run.
• Risk and error reduction: Modern code is more readable, more understandably structured and less prone to errors. Bugs are found faster, downtimes are reduced and support costs are lowered.

How do you argue effectively?

1. Speak the language of management: Focus on business metrics, not technical details. Instead of “Pattern Matching is more elegant” rather: “We reduce development time and lower maintenance costs through clearer code.” Instead of “ZGC enables low-pause garbage collection” better: “Customers experience fewer dropouts and faster response times – a measurable competitive advantage.”
2. Use practical examples: Show how similar companies or other teams in your own company have benefited from modernization. You can find a selection of impressive examples in the box “Concrete practical examples” at the end of the section.
3. Prepare decision templates: Summarize benefits, effort and possible risks in a compact way. A well-structured presentation or a compact PDF can already make the difference.
4. Show the Return on Investment (ROI): Show how quickly the investment in an upgrade or training pays for itself – for example through savings, faster time-to-market or fewer support tickets.
5. Offer concrete next steps: A non-binding modernization workshop or targeted proof of concept quickly delivers initial results and makes the benefits of new features tangible – without changing existing processes.

Conclusion:

Management rarely decides purely technically – it needs comprehensible figures, risks and opportunities. If you manage to translate the technical added value of modern Java development into measurable, entrepreneurial advantages, you create the basis for willingness to invest and strategic support.

In the next chapter, we’ll take a look at which path to modernization might be the best fit for your company – bottom-up, top-down or together.

Which Path Suits You? Bottom-up, Top-Down – or Together?

As soon as the desire for modernization is in the room, the question arises: How do you best get the change rolling? Do you wait for a clear signal from above, do you start yourself in the team – or do you look for a common path with management? Each of these approaches has strengths and weaknesses. The most effective is often a clever combination.

Bottom-up: the Initiative from the Team

Many successful modernization projects arise because individual developers or small groups take the first step. They try out new features, prepare examples and present them in the team or company-wide in brownbag sessions.

Benefits:

• Practical examples and quick wins are often more convincing than abstract arguments.
• The team develops initiative and motivation.
• Acceptance is usually higher because the change arises from everyday work.

Risks:

• Without backing from management, important resources or budgets are often lacking.
• Changes may remain limited to individual projects and not reach the entire company.

Top-down: Management Sets the Direction

In some companies, the initiative comes from management. The leadership strategically decides on an upgrade and implements the modernization course in a binding manner.

Benefits:

• Resources and budgets are secured.
• The direction is clear and consistent – even across team boundaries.
• Decisions can be made and implemented more quickly.

Risks:

• If the team is not involved, resistance can easily arise – the project seems like a measure imposed from above.
• Without technical expertise in the decision-making process, important framework conditions from the developers’ everyday work might not be sufficiently considered.

Strong Together: the Hybrid Approach

The best results are achieved when bottom-up engagement and top-down support go hand in hand. The team contributes ideas and concrete use cases – the management provides the structural framework, resources, freedom, and creates strategic commitment.

How to make the collaboration succeed:

• Early, open communication between tech leads, the team, and the management level.
• Jointly defined pilot projects that consider both technical and economic goals.
• Feedback loops: Experiences from the team are systematically incorporated into further planning and prioritization.
• Visible successes – for example, through small lighthouse projects that also inspire other teams.

Conclusion:

Whether bottom-up, top-down, or together – the crucial thing is that all participants are picked up, involved, and empowered early on. Change does not succeed through pressure, but through understanding, participation, exchange, and initial positive experiences.

In the next chapter, I’ll show you how you can actively shape this process – and how you can use it to build a sustainable culture of change.

Conclusion: Start Now – and Bring Everyone Along

The introduction of modern Java versions is not a sure thing – but it is worth it. If you manage to inspire both your team and management with the advantages, you create the basis for sustainable progress: more maintainable code, motivated developers, and visible business advantages.

The most important learnings at a glance:

• Show real benefits in everyday work: Features like Records, Pattern Matching, or Virtual Threads are convincing not through theory, but through concrete simplifications in everyday work.
• Speak openly about concerns: Uncertainties are normal. A learning culture in which questions are welcome creates trust and openness to new things.
• Translate technical advantages into business language: Decision-makers want to see results – lower cloud costs, higher velocity, decreasing maintenance effort.
• Rely on pilot projects and quick wins: First small modernizations – visible, tangible, low-risk – create trust and motivation for the next steps.
• Understand modernization as a process: Not a “Big Bang”, but a structured path. With a clear roadmap, iterative implementation, and continuous learning support.

Most importantly: Just start – with a small step. You don’t have to modernize everything at once. Even a small example, a brownbag session, or an exploration branch can be the beginning. Share your experiences, involve others – and stick with it, even if there are setbacks.

Every step creates clarity, trust, and direction – and brings you and your team closer to a modern, maintainable, future-proof Java project.

Do you have questions, need concrete arguments for your next meeting, or want to initiate a modernization project?

Feel free to write to me or bring your experiences and ideas to the comments – I look forward to the exchange!

Java 25 has been released on September 16, 2025. You can download it here.

My Java 25 highlights:

• Two years after Virtual Threads, Scoped Values are now also a production feature. With Scoped Values, data can be provided across method chains without having to pass them as parameters from method to method.
• Compact Source Files and Instance Main Methods: For small test and demo programs, as often written when trying out new features, a class declaration is no longer required, and the signature of the main() method has been greatly simplified: more than void main() is no longer necessary.
• With Flexible Constructor Bodies, we are now allowed to execute code in the constructor before calling super() or this(). This allows, for example, validating or calculating parameters before calling the super constructor.
• With Compact Object Headers, object headers can be compressed from 12 to 8 bytes. This saves memory space and improves performance, especially in applications with many small objects.
• With Stable Values (currently still in preview stage), values can be initialized thread-safely on first access – then they are considered constants and can be optimized by the JVM like final fields, e.g., through constant folding.

Scoped Values – JEP 506

With Java 25, the second feature from “Project Loom” (after Virtual Threads) is completed: After several rounds as an incubator and preview feature, Scoped Values have now also been finalized.

Scoped Values offer an elegant way to make data available across method chains without having to pass them as parameters. Typical example: In a web application, after successful authentication, the logged-in user is stored in a Scoped Value. All subsequent methods – no matter how deep in the call stack they are called – can then directly access this User object:

public class Server {
  public static final ScopedValue<User> LOGGED_IN_USER = ScopedValue.newInstance();

  private void serve(Request request) {
    User loggedInUser = authenticateUser(request);
    ScopedValue.where(LOGGED_IN_USER, loggedInUser)
               .run(() -> restAdapter.processRequest(request));
  }
}Code language: Java (java)

Within the call of restAdapter.processRequest(...), the logged-in user can be retrieved at any time via LOGGED_IN_USER.get() – without explicit passing as a parameter. The mechanism is reminiscent of ThreadLocal, but has several advantages:

• Limited scope: The scope is clearly defined and automatically ends with the expiration of run() or call().
• Immutability: The stored value cannot be changed – unlike ThreadLocal – which prevents race conditions and unexpected side effects.
• Lower memory footprint: When using InheritableThreadLocal, values are copied to child threads so that changes in the child thread do not affect the parent thread. Due to immutability, it is not necessary to copy values with Scoped Values.

Scoped Values were first introduced in Java 20 as an incubator feature. With Java 23, they were extended by the generic interface ScopedValue.CallableOp, which enables type-safe exception handling. In Java 24, the convenience methods callWhere() and runWhere() were removed – in favor of a more consistent, fluent style:

// Before Java 24:
Result result = ScopedValue.callWhere(LOGGED_IN_USER, loggedInUser, 
                                      () -> doSomethingSmart());

// Since Java 24:
Result result = ScopedValue.where(LOGGED_IN_USER, loggedInUser)
                           .call(() -> doSomethingSmart());Code language: Java (java)

In Java 25, Scoped Values are finalized through JDK Enhancement Proposal 506 and can thus be used in production code.

If you have been using ThreadLocal so far, it’s worth taking a look at the new possibilities. Scoped Values not only offer better readability and maintainability but also fit perfectly into the new world of virtual threads.

👉 You can find a detailed introduction in the main article about Scoped Values.

Module Import Declarations – JEP 511

After two rounds as a preview in Java 23 and Java 24, Module Import Declarations have also been finalized in Java 25 through JDK Enhancement Proposal 511 – without further changes.

What Does import module Do?

Since Java 1.0, classes from the package java.lang have been automatically made available. We have always been able to include entire packages with the import statement. What was not possible for a long time: importing entire modules. This is now made possible by import module.

A module import allows you to use all classes from the exported packages of a module:

import module java.base;

public static Map<Character, List<String>> groupByFirstLetter(String... values) {
  return Stream.of(values).collect(
      Collectors.groupingBy(s -> Character.toUpperCase(s.charAt(0))));
}Code language: Java (java)

In the example above, you don’t need to import java.util.List or java.util.stream.Collectors individually – they all belong to the java.base module.

Important: You don’t need a module-info.java for this. Even classic projects without modules benefit from the new mechanism.

Name Conflicts with Multiple Occurring Classes

When two imported modules provide a class with the same name, the compiler cannot immediately know which one is needed. An example is the class Date – it is contained in both java.base and java.sql:

import module java.base;
import module java.sql;

// . . .

Date date = new Date();  // Compiler error: "reference to Date is ambiguous"Code language: Java (java)

The solution? You specify which variant you want to use through an explicit class name import:

import module java.base;
import module java.sql;
import java.util.Date;  // ⟵ This resolves the ambiguity

// . . .

Date date = new Date();Code language: Java (java)

Since Java 24, you can also resolve such conflicts through package imports:

import module java.base;
import module java.sql;
import java.util.*; // ⟵ This also resolves the ambiguity

// . . .

Date date = new Date();Code language: Java (java)

Transitive Module Dependencies

A major advantage of import module lies in the support of transitive dependencies: When a module transitively includes another, its exported packages are also available – without any additional import.

Example: java.sql declares a transitive dependency on java.xml:

module java.sql {
  requires transitive java.xml;
}Code language: Java (java)

This allows you to directly use classes like SAXParserFactory without explicitly importing java.xml:

import module java.sql;

SAXParserFactory factory = SAXParserFactory.newInstance();Code language: Java (java)

New in Java 24 (and now final in Java 25) is that java.base also works as a transitive dependency – for example, when you import java.se, which previously had not transitively included java.base.

Effects on JShell and Compact Source Files

JShell and the so-called Compact Source Files, which are also finalized in Java 25 and described in the next section, now automatically import java.base. This reduces boilerplate code in interactive sessions and in compact source files.

👉 You can find more background information, practical examples, and in-depth explanations in the main article about Module Import Declarations.

Compact Source Files and Instance Main Methods – JEP 512

When Java beginners write their first program, it often looks like this:

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello world!");
  }
}Code language: Java (java)

For experienced developers, this may seem completely self-evident – but beginners are overwhelmed by visibility modifiers like public, classes, static methods, an unused args array, and a somewhat cumbersome System.out.

With Java 25, all of this becomes optional. Compact Source Files and Instance Main Methods – finalized through JDK Enhancement Proposal 512 after four preview rounds with varying feature names – enables compact Java programs without explicit class structure:

void main() {
  IO.println("Hello world!");
}Code language: Java (java)

Functionality in Detail

A Compact Source File is a .java file that contains no explicit class or package declaration. When compiling, the Java compiler automatically generates a so-called implicitly declared class. This class is not visible and cannot be referenced by other classes.

The main() method – whether in conventional or compact source files – no longer needs to be static or public, and the args parameter is also optional. If the method is not static, i.e., it’s an instance method, an instance of the class is automatically created when the program starts, and the main() method of this instance is called.

The new IO class provides the three most important input and output methods with print(), println(), and readln(). It is located in the java.lang package and is thus automatically available in all Java files without an import statement.

In compact source files, the module java.base is automatically imported. This means all classes of the packages exported by this module are immediately available (i.e., without imports). You can find more information about module imports in the Module Import Declarations section.

Why is this Important?

These innovations make getting started with Java noticeably easier. Compact programs like this can be executed directly:

void main() {
  IO.println(greet("world"));
}

String greet(String name) {
  return "Hello " + name + "!";
}Code language: Java (java)

The full expressiveness of the language is retained, just with significantly less syntactic overhead. Classes, modifiers, packages, modules can then be introduced when they are needed – as soon as the programs grow larger and require more structure.

Review

In Java 21, the feature was first introduced under the name Unnamed Classes and Instance Main Methods.

In Java 22, the concept of “unnamed classes” was replaced by “implicitly declared classes”. At the same time, the launch protocol that controls which main()-method is executed if multiple main()-methods exist was simplified.

In Java 23, the java.io.IO-helper class was introduced.

In Java 24, the feature was renamed to Simple Source Files and Instance Main Methods without any other changes.

In Java 25, the feature was finalized by JDK Enhancement Proposal 512 and renamed one last time to Compact Source Files and Instance Main Methods. The IO class, which was previously in the java.io package and whose methods were automatically statically imported, was moved to the java.lang package, and its methods must be explicitly imported. Thus, there is no longer a special rule for this one class.

👉 You can find further details about the main()-method, the “launch protocol” and special cases in the section Compact Source Files and Instance Main Method in the article about the main()-method.

Flexible Constructor Bodies – JEP 513

Constructors in Java were long strictly limited in their structure: no custom code was allowed before calling super(…) or this(…). This often led to sometimes cumbersome constructions – especially when wanting to validate or pre-calculate parameters.

The Problem so Far: Cumbersome Constructor Logic

An example makes this clear:

public class Square extends Rectangle {
  public Square(Color color, int area) {
    this(color, Math.sqrt(validateArea(area)));
  }

  private static double validateArea(int area) {
    if (area < 0) throw new IllegalArgumentException();
    return area;
  }

  private Square(Color color, double sideLength) {
    super(color, sideLength, sideLength);
  }
}Code language: Java (java)

Here, the validation must be outsourced to a separate method and the conversion of the area to a side length to a separate constructor. Why? Because (until now) super(...) or this (...) always had to be the first statement in a constructor.

This makes the code unnecessarily complex and hard to read – as you surely noticed at first glance at the code ;-)

Flexible Constructors in Java 25

Since Java 25, this anti-pattern is a thing of the past – thanks to “Flexible Constructor Bodies” finalized by JDK Enhancement Proposal 513.

From now on, the rule is: Any code may precede the call to super(...) or this(...) – as long as it doesn’t read from uninitialized instance fields.

This means:

• You can validate parameters.
• You can calculate local variables.
• You can even initialize fields – and this is especially helpful when the super constructor calls methods that are overridden in the subclass.

This leads to much more readable code:

public class Square extends Rectangle {
  public Square(Color color, int area) {
    if (area < 0) throw new IllegalArgumentException();
    double sideLength = Math.sqrt(area);
    super(color, sideLength, sideLength);
  }
}Code language: Java (java)

Here it is clear at first glance what happens:

1. The area is validated.
2. The side length is calculated
3. The Rectangle constructor is called.

Fewer Surprises with Inheritance

A frequently underestimated problem was also the following:

If a method is called in the super constructor, and that method is overridden in the subclass and accesses fields of the subclass there, this can lead to surprises.

Here’s an example:

public class SuperClass {
  public SuperClass() {
    logCreation();  // ⟵ 2.
  }

  protected void logCreation() {
    System.out.println("SuperClass created");  // ⟵ not invoked; 
                                               // method is overriden in ChildClass
  }
}

public class ChildClass extends SuperClass {
  private final String parameter;

  public ChildClass(String parameter) {
    super();                     // ⟵ 1.
    this.parameter = parameter;  // ⟵ 4.
  }

  @Override
  protected void logCreation() {
    System.out.println("parameter = " + parameter);  // ⟵ 3.
  }
}Code language: Java (java)

A call to new ChildClass("foo") would not output “SuperClass created” or “parameter = foo”. No, this call would output the following:

parameter = nullCode language: plaintext (plaintext)

The reason: parameter is only set in step 4 (see source code comments) – i.e., after the super constructor call. The method logCreation() called by the super constructor, which is overridden by ChildClass, therefore accesses an uninitialized field in step 3.

With Flexible Constructor Bodies, this can be easily prevented:

public ChildClass(String parameter) {
  this.parameter = parameter;
  super();
}Code language: Java (java)

We can now assign fields before we call the super constructor.

Review

Flexible Constructor Bodies started in Java 22 under the name “Statements before super(…)”.

In Java 23, the feature received its current name, and the possibility to initialize fields before calling the super constructor was added.

In Java 24, the feature was re-proposed as a preview without changes.

In Java 25, the feature is finalized without changes through JDK Enhancement Proposal 513 and can thus be used in production code.

👉 You can find further use cases, details, and peculiarities in the main article: Flexible Constructor Bodies in Java: Call Code Before super()

Performance Improvements

Java 25 brings performance improvements in various areas of the JVM: Compact Object Headers make memory usage more efficient; Generational Shenandoah optimizes garbage collection. Additionally, there are two extensions to the Ahead-of-Time Class Loading and Linking feature released in Java 24.

Compact Object Headers – JEP 519

Every Java object contains an object header in addition to the actual data fields. This header contains metadata such as the object’s hash code, lock information (for synchronization), object age (for garbage collection), and a pointer to the class data structure.

Until now, this header was typically 12 bytes in size – even 16 bytes with Compressed Class Pointers disabled.

As part of Project Lilliput, JDK developers have managed to reduce the header to 8 bytes – without losing functionality. This more compact variant is called Compact Object Header and saves considerable memory, especially with a large number of small objects.

Structure of the Previous 12-Byte Object Header

This is how the 12-byte header looks so far:

The 12-byte header consists of:

• a Mark Word containing the object’s identity hash code, its age, and two so-called tag bits (for synchronization)
• and a Class Word with a compressed pointer to the class data structure.

Structure of the “Compact” 8-Byte Object Header

And this is how the new 8-byte header is structured (Note: scale changed):

The Compact Object Header is no longer divided into Mark Word and Class Word. It now consists of:

• 22 bits for the class pointer (instead of 32 previously),
• 31 bits for the identity hash code (unchanged),
• 4 reserved bits for Project Valhalla,
• 4 bits for the object age (unchanged),
• 2 bits for locking information (tag bits, unchanged),
• 1 bit for the new Self Forwarded Tag.

What has changed?

1. Unused bits removed: In the previous structure, there were 27 unused bits in the Mark Word – these have been removed.
2. Class Pointer compressed: The 32-bit pointer to the class data structure has been reduced to 22 bits – you can learn exactly how this works in the main article about Compact Object Headers.

In Java 24, Compact Object Headers were introduced as an experimental feature. As they have proven to be stable and performant, they are declared a productive feature in Java 25 through JDK Enhancement Proposal 519.

You can activate them with the following VM option:

-XX:+UseCompactObjectHeaders

The additional enabling of experimental features through -XX:+UnlockExperimentalVMOptions is no longer required in Java 25.

You can find more details in the main article about Compact Object Headers mentioned above.

Generational Shenandoah – JEP 521

In Java 24, the Generational Mode for the Shenandoah garbage collector was introduced as an experimental feature.

A Generational Garbage Collector takes advantage of the so-called “Weak Generational Hypothesis”: Most objects die shortly after their creation, while long-lived objects typically continue to exist for longer.

To efficiently utilize this property, the garbage collector divides the heap into two areas – a young and an old generation. New objects initially land in the Young Space. Only if they survive multiple GC cycles are they moved to the Old Space. Due to the expected stability of the old generation, it is scanned less frequently – this reduces the number of unnecessary scans and ideally shortens pause times significantly.

This strategy is not new: The G1 Garbage Collector – in use since Java 7 – has always worked on a generational basis. The ZGC has also been using a comparable approach by default since Java 23. With Java 24, Shenandoah followed suit, initially only in experimental mode. The implementation proved to be stable and efficient in practice: Users reported positive results with latency-sensitive applications.

In Java 25, the Generational Mode is now declared a productive feature through JDK Enhancement Proposal 521. You can now activate it as follows:

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

The additional option -XX:+UnlockExperimentalVMOptions is no longer required.

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

When starting a Java application, it can sometimes take seconds to minutes until all Java classes are read, parsed, loaded, and linked. Through Ahead-of-Time Class Loading and Linking introduced in Java 24, which is based on Application Class Data Sharing (AppCDS), these steps can be executed before the application starts, thereby significantly accelerating the application’s startup.

The process previously consisted of three steps:

Step 1: In “Record Mode”, the JVM analyzes the application in a training run and stores information about the loaded and linked classes in the AOT configuration (in the example AotTest.conf):

java -XX:AOTMode=record -XX:AOTConfiguration=AotTest.conf \
    -cp AotTest.jar eu.happycoders.AotTestCode language: plaintext (plaintext)

Step 2: In “Create Mode”, the JVM generates the AOT cache (AotTest.aot) from the AOT configuration:

java -XX:AOTMode=create -XX:AOTConfiguration=AotTest.conf -XX:AOTCache=AotTest.aot \
    -cp AotTest.jarCode language: plaintext (plaintext)

Step 3: On each subsequent start of the application, the JVM loads the classes in loaded and linked form directly from this cache and starts correspondingly faster:

java -XX:AOTCache=AotTest.aot -cp AotTest.jar eu.happycoders.AotTestCode language: MIPS Assembly (mipsasm)

(In the article linked above, you will be guided step by step through this process.)

JDK Enhancement Proposal 514 introduces the new command-line option -XX:AOTCacheOutput, which allows the first two steps to be executed with a single command:

java -XX:AOTCacheOutput=AotTest.aot -cp AotTest.jar eu.happycoders.AotTestCode language: plaintext (plaintext)

Through a new environment variable JDK_AOT_VM_OPTIONS, you can specify VM options that should only apply to the second sub-step (“Create Mode”) – without affecting the first sub-step, the training run (“Record Mode”).

The new combined mode does not replace the two old modes, as there are use cases where it may still make sense to execute the steps separately. For example, if step 1 (the training run) should be executed on a small cloud instance – while step 2 (cache generation, which may take significantly longer in the future due to new optimizations) should be run on a more powerful machine.

Ahead-of-Time Method Profiling – JEP 515

When a Java application is running, the JVM continuously collects data about the called methods, especially about which methods require the most CPU time. These methods are then dynamically optimized and translated into assembler code for the target platform. Since this process takes a while, a Java application is slower at the beginning – in the so-called “warm-up phase” – and only reaches its full performance after a few seconds.

Through Ahead-of-Time Class Loading and Linking, as described in the previous section, a training run creates an AOT cache that contains the classes needed by an application in loaded and linked form, thus accelerating the start of an application.

JDK Enhancement Proposal 515 extends the training run and AOT cache so that, in addition to the binary class data, the aforementioned data on CPU usage of methods (so-called “method profiles”) are also stored in the AOT cache.

Thus, at program start, the most frequently called methods (the so-called “hotspots”) can be directly translated into machine code. This has resulted in measured improvements in startup time of up to 19%, while the size of the AOT cache has only increased by 2.5%.

The changes introduced by JEP 515 do not affect the continuous analysis of method calls and further optimization at runtime, so the application continues to be continuously optimized by the JVM when its behavior changes in production.

Improvements to Java Flight Recorder (JFR)

Java Flight Recorder (JFR) is a tool built into the JVM since Java 11 for diagnosing Java applications. With the JFR, you can profile the application and capture certain events without significantly impacting the application’s performance.

Java 25 includes three improvements to the Java Flight Recorder – one of which is still in Experimental status.

JFR Cooperative Sampling – JEP 518

One function of the Java Flight Recorder is “profiling”. This is not about individual events, but about statistics, e.g., on which methods take up how much time.

This is not done by exact measurement, but by so-called “sampling”: At fixed intervals, the call stacks of all threads are read and stored. From the stored call stacks, the approximate call duration of all methods is then derived using statistical methods.

However, reading an exact stack trace is only possible at so-called “safepoints” – these are designated points in the JVM code where certain required metadata is available. Reading exclusively at these safepoints, however, leads to the so-called “safepoint bias”: If frequently called code is executed disproportionately often far from a safepoint, it is measured inaccurately.

For this reason, sampling has not been performed only at these safepoints until now. However, without the metadata available at the safepoints, heuristics had to be used to generate the call stack. These heuristics are extremely inefficient and can, in the worst case, cause the JVM to crash.

Therefore, the sampling mechanism was modified as follows through JDK Enhancement Proposal 518:

• At regular sampling intervals, only the CPU’s program counter and stack pointer are read.
• Stack traces are read at the subsequent safepoints.
• The call stack at the sampling time is reconstructed using the recorded program counter and stack pointer.

This approach is more performant on the one hand, and simpler in implementation and therefore more stable on the other.

JFR Method Timing & Tracing – JEP 520

In the previous section, I described how the Java Flight Recorder (JFR) profiling works: At certain points in time, call stacks of all threads are read, and the approximate call frequencies and durations of all methods are derived through statistical calculations. However, this method is inaccurate and will never be able to determine the exact number of calls and duration.

Third-party providers such as JProfiler, YourKit or DataDog have always provided tools that connect to the JVM as a so-called Java agent and inject code into the methods to be measured, which precisely measures the call frequency and duration. This, of course, results in a certain overhead.

JDK Enhancement Proposal 520 now creates the possibility within the JVM to measure method calls and their duration precisely. Filters can be used to select specific classes, specific methods, or methods with specific annotations. The advantages: higher accuracy compared to sampling and less overhead compared to using third-party agents.

For example, you can log the stack trace of all interactions with HashMaps using the following options:

java -XX:StartFlightRecording:jdk.MethodTrace#filter=java.util.HashMap,filename=recording.jfr Demo.javaCode language: plaintext (plaintext)

Then you can print the stack traces like this:

jfr print --events jdk.MethodTrace --stack-depth 20 recording.jfrCode language: plaintext (plaintext)

You can log and print the call times as follows:

java -XX:StartFlightRecording:jdk.MethodTiming#filter=java.util.HashMap,filename=recording.jfr Demo.java
jfr print --events jdk.MethodTiming recording.jfrCode language: plaintext (plaintext)

JFR CPU-Time Profiling (Experimental) – JEP 509

In the JFR Cooperative Sampling section, I described how the call frequency and duration of methods can be derived by reading stack traces at fixed intervals.

The times determined in this process are the so-called execution time, i.e., the time that has elapsed from entering the method to exiting it. This time is independent of how the method has used the CPU. A method that executes a sorting algorithm for one second, utilizing 100% of the CPU, has the same execution time as a method that sends a request to the database and waits one second for the response – which, in contrast, uses only minimal CPU resources.

The time during which the method uses the CPU is called CPU time.

If we know which methods use the most CPU time, we can optimize these methods, for example, by replacing a search algorithm with a more efficient one – and thereby reduce the CPU load of the application.

Until now, the Java Flight Recorder did not offer a way to analyze CPU time. This changes with JDK Enhancement Proposal 509 – initially, however, only for Linux.

The new option jdk.CPUTimeSample#enabled=true allows you to activate CPU time sampling. For example, the following command starts a Java application with CPU time sampling activated and outputs the measured data to the file profile.jfr:

java -XX:StartFlightRecording=jdk.CPUTimeSample#enabled=true,filename=profile.jfr ...Code language: plaintext (plaintext)

The new option is independent of the option jdk.ExecutionSample#enabled=true, which activates execution time sampling – so you can activate both sampling methods simultaneously and measure execution times and CPU times.

CPU-Time Profiling is currently only available for Linux and is still in the experimental stage. Since it is not a regular VM option, but a JFR option, you do not need to specify the VM option -XX:+UnlockExperimentalVMOptions to activate it.

New Preview Features in Java 25

Even though Java 25 is a long-term support release, that’s no reason for JDK developers not to publish new preview features. A particularly interesting preview feature is Stable Values – values that are initialized once when first accessed and then remain constant, allowing the JVM to optimize access to them.

Preview features are not intended for production use, but for initial experimentation and must be activated with the following VM options:

--enable-preview --source 25

Stable Values (Preview) – JEP 502

Stable Values solve an old problem – the clean, performant, and thread-safe initialization of values that should not (or cannot) be set at program startup, but only upon first access.

Why Do We Need Stable Values?

Immutable values make code simpler, safer, and allow the JVM to perform extensive performance optimizations such as constant folding. Until now, this was only possible by marking a field as final. However, final fields are initialized immediately when a class is loaded (final static fields) or when an object is created (final instance fields).

But if the initialization is complex or context-dependent – for example, because a service is only available later – we have to make do with various forms of lazy initialization. Trivial implementations are often not thread-safe, and thread-safe variants, such as the double-checked locking idiom, are difficult to implement correctly and thus error-prone. In the end, all available solutions are workarounds and exclude JVM optimizations.

Here’s an example of a trivial, non-thread-safe implementation to load program settings from a database upon first access:

private Settings settings;

private Settings getSettings() {
  if (settings == null) {
    settings = loadSettingsFromDatabase();
  }
  return settings;
}

public Locale getLocale() {
  return getSettings().getLocale();
}Code language: Java (java)

With synchronized, we could make the getSettings() method thread-safe, but that wouldn’t be very performant. You can find a thread-safe and performant – but significantly more complex – variant in the Optimized Double-Checked Locking in Java section of the article on double-checked locking.

The solution: Stable Values

Stable Values bridge the gap between final and mutable:

• They can be initialized exactly once – at any time and in a thread-safe manner.
• After that, they are considered immutable, allowing the JVM to optimize them like final fields.
• They eliminate typical sources of errors in self-built lazy initializations.

Here’s the example from above with a Stable Value:

private final Supplier<Settings> settings =
    StableValue.supplier(this::loadSettingsFromDatabase);

public Locale getLocale() {
  return settings.get().getLocale(); // ⟵ Here we access the stable value
}Code language: Java (java)

On the first call to settings.get(...), loadSettingsFromDatabase() is called and the settings are cached within settings. All subsequent accesses then return the cached value. This all happens in a thread-safe manner, meaning if get(...) is called simultaneously from multiple threads, loadSettingsFromDatabase() is only called in one of the threads. The other threads wait until the value is available.

Also Usable as a List

With StableValue.list(), you can define a list whose elements are initialized upon access and then frozen. Example:

List<Double> squareRoots = StableValue.list(100, Math::sqrt);Code language: Java (java)

Only upon the first access to a list element – whether with first(), get(int index), last(), or during an iteration – is it calculated. After that, it remains constant, and further accesses to it can be optimized by the JVM – just like accesses to constants.

In addition to Stable Lists, there are also Stable Maps, Stable Functions, and Stable IntFunctions.

You can find the complete Stable Value API, along with a detailed explanation of its internal workings, in the main article on Stable Values (or Lazy Constants, as they have been called since Java 26). There I also take a closer look at the previous workarounds and their drawbacks.

Stable Values have been released in Java 25 as a preview feature through JDK Enhancement Proposal 502.

PEM Encodings of Cryptographic Objects (Preview) – JEP 470

PEM (Privacy-Enhanced Mail) is a widely used format for storing cryptographic keys and certificates. A certificate in PEM format looks like this, for example:

-----BEGIN CERTIFICATE-----
MIIDtzCCAz2gAwIBAgISBUCeYELtjMmr4FAIqHapebbFMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
. . .
DBeMde1YpWNXpF9+B/OMKgn7RgXRj5b2QpBCnFsP92T4cK/Nn+xFIjYCMCCx4E79
toSQBlYnNHv0eXnWkI8TmXsU/A6rU4Gxdr9GbGixgRJvkw0C6zjL/lH2Vg==
-----END CERTIFICATE-----Code language: plaintext (plaintext)

Anyone who has ever tried to import keys or certificates in PEM format into a Java application or export them from it will have discovered after painstaking Stack Overflow research: Java does not offer a direct way to do this.

For example, decoding an encrypted private key in PEM format requires more than a dozen lines of code:

String encryptedPrivateKeyPemEncoded = . . .
String passphrase = . . .

String encryptedPrivateKeyBase64Encoded = encryptedPrivateKeyPemEncoded
    .replace("-----BEGIN ENCRYPTED PRIVATE KEY-----", "")
    .replace("-----END ENCRYPTED PRIVATE KEY-----", "")
    .replaceAll("[\\r\\n]", "");

Base64.Decoder decoder = Base64.getDecoder();
byte[] encryptedPrivateKeyBytes = decoder.decode(encryptedPrivateKeyBase64Encoded);
EncryptedPrivateKeyInfo encryptedPrivateKeyInfo =
    new EncryptedPrivateKeyInfo(encryptedPrivateKeyBytes);

String algorithmName = encryptedPrivateKeyInfo.getAlgName();
SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance(algorithmName);

PBEKeySpec pbeKeySpec = new PBEKeySpec(passphrase.toCharArray());
Key pbeKey = secretKeyFactory.generateSecret(pbeKeySpec);

Cipher cipher = Cipher.getInstance(algorithmName);
AlgorithmParameters algParams = encryptedPrivateKeyInfo.getAlgParameters();
cipher.init(Cipher.DECRYPT_MODE, pbeKey, algParams);

KeyFactory rsaKeyFactory = KeyFactory.getInstance("RSA");
KeySpec keySpec = encryptedPrivateKeyInfo.getKeySpec(cipher);
PrivateKey privateKey = rsaKeyFactory.generatePrivate(keySpec);Code language: Java (java)

The feature PEM Encodings of Cryptographic Objects introduced in Java 25 as a preview is intended to significantly simplify this. The code monster above can be simplified in Java 25 with activated preview features as follows:

PrivateKey privateKey = PEMDecoder.of()
    .withDecryption(passphrase.toCharArray())
    .decode(encryptedPrivateKeyPemEncoded, PrivateKey.class);Code language: Java (java)

18 lines of code have been reduced to three lines!

It’s just as easy to encrypt a private key and convert it to PEM format:

String encryptedPrivateKeyPemEncoded = PEMEncoder.of()
    .withEncryption(passphrase.toCharArray())
    .encodeToString(privateKey);Code language: Java (java)

At the center of the new feature are the classes PEMEncoder and PEMDecoder as well as the interface DEREncodable:

• All classes that represent cryptographic keys and certificates (like PrivateKey in the example above) implement the new interface DEREncodable.
• A PEMEncoder is created – as shown above – with the static method PEMEncoder.of(). The instance methods encode(...) and encodeToString(...) can then be used to convert cryptographic objects to PEM format (binary or as a string).
• A PEMDecoder is created with the static method PEMDecoder.of(). PEM files can then be converted into a cryptographic object using the decode() method.
• The PEMDecoder.decode() method also exists without the second parameter, which in the example above specifies the expected return type PrivateKey.class. This variant returns a DEREncodable, which can then be evaluated using Pattern Matching for switch, for example.
• To encrypt a private key, the PEMEncoder must be created with PEMEncoder.of().withEncryption(passphrase) – as in the example above. To decrypt it again, the PEMDecoder must be created analogously with PEMDecoder.of().withDecryption(passphrase).
• PEMEncoder– and PEMDecoder instances are stateless and thread-safe – thus a single instance can be shared and reused by multiple threads.
• If the decode() method cannot decode the PEM data, no exception is thrown, but a generic PEMRecord object is returned containing the binary data of the PEM file.

PEM Encodings of Cryptographic Objects is specified in JDK Enhancement Proposal 470.

Resubmitted Preview and Incubator Features

Three features didn’t make it to be finalized in Java 25 and are going into a new preview or incubator round: Structured Concurrency, Primitive Type Patterns, and – not surprisingly – the Vector API.

Structured Concurrency (Fifth Preview) – JEP 505

When a task can be broken down into multiple subtasks that can be executed independently and in parallel, you can use Structured Concurrency to coordinate these subtasks in a clearly structured, traceable, and efficient manner.

Instead of complex and error-prone logic with, for example, ExecutorService or parallel streams, we get an API that summarizes the start, completion, and error handling of all subtasks in a clearly defined code block.

Structured concurrency scopes can be nested arbitrarily. This allows you to clearly model complex task structures while maintaining an overview and control over the lifecycle of all subtasks at all times:

With Java 25, Structured Concurrency is already entering its fifth preview round – for the first time since the first preview version in Java 21, however, with significant changes to the API. The changes are specified in JDK Enhancement Proposal 505 and are based on extensive feedback from the community.

If you haven’t dealt with Structured Concurrency yet and therefore aren’t interested in the changes, feel free to jump directly to the section Example: The Fastest Response Wins.

What’s New in Java 25?

The way a StructuredTaskScope is opened has been fundamentally revised:

• Instead of using new and the constructor, a StructuredTaskScope is now opened via the static factory method StructuredTaskScope.open().
• If open() is called without parameters, a StructuredTaskScope is created that waits for all subtasks to complete successfully … or one subtask to fail – just like the previous specialized implementation ShutdownOnFailure. Thus, new StructuredTaskScope.ShutdownOnFailure() becomes StructuredTaskScope.open().
• Other strategies are no longer created by deriving from StructuredTaskScope, but by a so-called joiner, which is passed as a parameter to the open() method.
• The Joiner interface defines static factory methods to create joiners for frequently needed strategies.
• Joiner.anySuccessfulResultOrThrow() creates a joiner that returns a result as soon as the first subtask is successful – just like the specialized StructuredTaskScope implementation ShutdownOnSuccess did before. Thus, new StructuredTaskScope.ShutdownOnSuccess() becomes StructuredTaskScope.open(Joiner.anySuccessfulResultOrThrow()).
• Custom join strategies can be implemented by implementing the Joiner interface instead of extending StructuredTaskScope.

Additionally, the completion of processing has been simplified:

• The method StructuredTaskScope.result() has been removed – now StructuredTaskScope.join() returns the result. For example, scope.join(); return scope.result(); thus becomes return scope.join();
• Similarly, the method StructuredTaskScope.throwIfFailed() has been removed – in case of an exception, it is now also thrown by StructuredTaskScope.join(). This makes error handling more robust.
• StructuredTaskScope.join() no longer throws a generic ExecutionException in case of an error, but a Structured Concurrency-specific FailedException or a TimeoutException.

Here you can see the changes using the example of the race() method, which I have shown in some previous articles:

Old implementation up to Java 24:

public static <R> R race(Callable<R> task1, Callable<R> task2)
    throws InterruptedException, ExecutionException {
  try (var scope = new StructuredTaskScope.ShutdownOnSuccess<R>()) {
    scope.fork(task1);
    scope.fork(task2);
    scope.join();
    return scope.result();
  }
}Code language: Java (java)

New implementation from Java 25:

public static <R> R race(Callable<R> task1, Callable<R> task2)
    throws InterruptedException {
  Joiner<R, R> joiner = Joiner.anySuccessfulResultOrThrow();
  try (var scope = StructuredTaskScope.open(joiner)) {
    scope.fork(task1);
    scope.fork(task2);
    return scope.join();
  }
}Code language: Java (java)

These changes decouple StructuredTaskScope and join strategy, leading to more flexible and maintainable code (keyword: Composition over inheritance).

Example: the Fastest Response Wins

A common scenario is querying multiple services in parallel, where the first valid response should be used – in the following example when obtaining weather data:

WeatherResponse getWeatherFast(Location location) throws InterruptedException {
  Joiner<WeatherResponse, WeatherResponse> joiner = Joiner.anySuccessfulResultOrThrow();
  try (var scope = StructuredTaskScope.open(joiner)) {
    scope.fork(() -> weatherService.readFromStation1(location));
    scope.fork(() -> weatherService.readFromStation2(location));
    scope.fork(() -> weatherService.readFromStation3(location));
    return scope.join();
  }
}Code language: Java (java)

As soon as one of the tasks is successful, the others are automatically canceled. The scope.join() method returns the result of the first successful task or throws a FailedException if no task was completed successfully.

Without Structured Concurrency, you would have to implement the same task with significantly more code, manual thread handling, and custom error logic – which would not only be more time-consuming but also much more prone to bugs.

Conclusion

With JEP 505, Structured Concurrency takes a big step towards finalization. The revised API is more clearly structured, easier to understand, and more robust in error handling.

It once again shows how valuable the feedback from the Java community is during the preview phase of a feature: Only through feedback from practical use could the weaknesses of the previous API be identified and specifically improved.

You can find a more detailed description and numerous other examples in the main article about Structured Concurrency.

Primitive Types in Patterns, Instanceof, and Switch (Third Preview) – JEP 507

Pattern Matching is one of the most exciting developments in recent years. What began with Pattern Matching for instanceof in Java 16 and was expanded with Pattern Matching for switch in Java 21 is now being extended – to primitive data types like int, double, or boolean.

Until now, pattern matching was limited to reference types. For example, like this:

switch (obj) {
  case String s when s.length() >= 5 -> System.out.println(s.toUpperCase());
  case Integer i                     -> System.out.println(i * i);
  case null, default                 -> System.out.println(obj);
}Code language: Java (java)

This wasn’t possible with primitive values. While you could long compare primitive values like int with constants in the classic switch …

int code = ...
switch (code) {
  case 200 -> System.out.println("OK");
  case 404 -> System.out.println("Not Found");
}Code language: Java (java)

… but this only worked with byte, short, char and int – but not with long, float, double or boolean. And instanceof didn’t work with primitive types at all.

This will change with Primitive Types in Patterns, instanceof, and switch:

• All primitive types (int, long, float, double, char, byte, short, boolean) can now be used in switch statements and expressions – both with constants and with pattern matching.

• Pattern matching with primitive types is now also possible with instanceof.

What Exactly Does Pattern Matching with Primitive Types Mean?

When pattern matching with reference types, you ask: “Is this object an instance of type XY or one of its subclasses?” With primitive types, it works differently because there is no inheritance. Instead, it checks: Can the current value be represented in a specific target type without loss of precision?

An example:

int i = ...
if (i instanceof byte b) {
  System.out.println("b = " + b);
}Code language: Java (java)

Here, i matches the pattern byte b if the value also fits in a byte. For i = 100 this would be the case, for i = 500 it wouldn’t.

Or with floating-point numbers:

double d = ...
if (d instanceof float f) {
  System.out.println("f = " + f);
}Code language: Java (java)

Here, the rule is: Only if d fits into a float without loss of precision does the pattern match. This works for d = 1.5, but not for d = Math.PI or d = 16.777.217. Both numbers are too precise to be stored in a 32-bit float variable.

You can – as with reference types – attach additional conditions:

int a = ...
if (a instanceof byte b && b > 0) {
  System.out.println("b = " + b);
}Code language: Java (java)

In this case, the pattern only matches if a can be represented losslessly as byte and the value is additionally greater than 0.

Pattern Matching with Switch and Primitive Types

This doesn’t just work with instanceof, but also with switch. Here’s a complete example:

double value = ...
switch (value) {
  case byte   b -> System.out.println(value + " instanceof byte:   " + b);
  case short  s -> System.out.println(value + " instanceof short:  " + s);
  case char   c -> System.out.println(value + " instanceof char:   " + c);
  case int    i -> System.out.println(value + " instanceof int:    " + i);
  case long   l -> System.out.println(value + " instanceof long:   " + l);
  case float  f -> System.out.println(value + " instanceof float:  " + f);
  case double d -> System.out.println(value + " instanceof double: " + d);
}Code language: Java (java)

Depending on the specific value, the first matching case is executed:

• For value = 42, for example, the pattern byte b matches because the value can be stored as byte without loss of information.
• For value = 200, byte no longer fits, but short does – so the short s branch is executed.
• For value = 65000, short also no longer applies, but char c does, as char can represent values from 0 to 65,535.
• For value = 500000, byte, short, and char are too small – here int i fits.
• For value = 3.14, no integer representation is possible, but the value fits into a float without loss of precision, so the branch behind float f is executed.
• For value = Math.PI, only double d remains, as Math.PI is too precise for float.

As with object types, the same applies here: You must cover all cases or specify a default branch to ensure exhaustive checking.

Subtleties: Dominance and Completeness

The principle of dominance also plays an important role for primitive types: An int value basically also fits into a long, so a pattern long l would also catch all int values – and therefore must not stand before a pattern int i in the code.

Additionally, as with all modern switch features, the rule of exhaustiveness applies: The switch block must cover all theoretically possible cases. If this is not possible or not sensible, you must define a default branch to avoid compiler errors.

You can find more about the exact rules for dominance and exhaustiveness, as well as further examples and peculiarities, in the main article Primitive Types in Patterns, instanceof and switch.

Review

Primitive Types in Patterns, instanceof, and switch was first introduced in Java 23 and reintroduced without changes as a preview in Java 24. In Java 25, it now goes into the third preview round, specified by JDK Enhancement Proposal 507 – again without changes, to gather further feedback from the Java community.

Vector API (Tenth Incubator) – JEP 508

The Vector API is presented for the tenth time in the incubator stage – specified by JDK Enhancement Proposal 508.

The API allows mathematical vector operations like the following to be executed particularly efficiently:

The JVM can map these operations so that they – depending on the vector size – directly access the vector instruction sets of modern CPUs. In many cases, such a calculation can be executed in a single CPU cycle.

The Vector API remains an incubator feature until the building blocks it requires from Project Valhalla have reached the preview stage. As soon as the Vector API is available in a first preview version, I will describe it in detail with practical examples.

Other Changes in Java 25

In this section, you’ll find changes that couldn’t be sorted into the other chapters. These are less prominent JEPs, removals, and some (selected by me from the release notes) minor changes that were implemented without a JEP.

Key Derivation Function API – JEP 510

A Key Derivation Function (KDF) allows additional cryptographic keys to be derived from a secret input value – such as a password, passphrase, or existing key.

For KDFs to be used consistently and implemented by security providers, a standardized interface is needed. This is exactly what JDK Enhancement Proposal 510 provides with the Key Derivation Function API and the javax.crypto.KDF class.

Through this API, you can load and use various KDF algorithms. In the following example, we use “HKDF-SHA256” to derive an AES key from a password and a salt:

void main() throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
  KDF hkdf = KDF.getInstance("HKDF-SHA256");

  AlgorithmParameterSpec params =
      HKDFParameterSpec.ofExtract()
          .addIKM("the super secret passphrase".getBytes(StandardCharsets.UTF_8))
          .addSalt("the salt".getBytes(StandardCharsets.UTF_8))
          .thenExpand("my derived key".getBytes(StandardCharsets.UTF_8), 32);

  SecretKey key = hkdf.deriveKey("AES", params);

  System.out.println("key = " + HexFormat.of().formatHex(key.getEncoded()));
}Code language: Java (java)

If you’re wondering about the compact main() method: This is part of the innovations covered in the Compact Source Files and Instance Main Methods section.

Explanations for the abbreviations used in the code can be found in the following Wikipedia articles:

• HKDF stands for “HMAC-based Key Derivation Function”.
• HMAC means “Hash-based Message Authentication Code”.
• IKM refers to the “input key material”, for example, the password.
• AES is the “Advanced Encryption Standard”, a widely used encryption algorithm.

When you run the example, you should get the following output:

key = 7ee15549ddce956194ca1d6df5aa34c1a1334d15c875e67ea67fb5850ee48b0cCode language: plaintext (plaintext)

The key generated in this way can be used, for example, as a session key for secure data transfer.

The Key Derivation Function API was first introduced in Java 24 as a preview feature and is now a permanent part of the JDK from Java 25 onwards, without changes compared to the preview version.

Remove the 32-Bit X86 Port – JEP 503

After the 32-bit port for Windows was removed in Java 24, the last remaining 32-bit variant – the one for Linux – is now being completely removed in Java 25 through JDK Enhancement Proposal 503.

This eliminates the extra effort for developing and testing 32-bit ports, allowing JDK developers to focus entirely on new features.

Relax String Creation Requirements in StringBuilder and StringBuffer

The specifications of the substring()-, subSequence()– and toString()-methods of the StringBuilder and StringBuffer classes previously required that a newly created String object is always returned. This requirement has been removed from the specification, so these methods can now, for example, return a "" constant for an empty string, which is faster than creating a new empty string.

There is no JEP for this change; it is listed in the bug tracker under JDK-8138614.

New Methods on BodyHandlers and BodySubscribers to Limit the Number of Response Body Bytes Accepted by the HttpClient

The classes java.net.http.HttpResponse.BodyHandlers and java.net.http.HttpResponse.BodySubsribers have each been extended with a limiting() method, which can be used to limit the size of a response to an HTTP request.

There is no JEP for this change; it is listed in the bug tracker under JDK-8328919.

The UseCompressedClassPointers Option is Deprecated

By default, the JVM works with Compressed Class Pointers – these are 32-bit compressed pointers in the object header that point to the class data structure belonging to the object.

Before Compressed Class Pointers were introduced, these pointers were 64 bits long on 64-bit systems. This mode can currently still be reactivated through -XX:-UseCompressedClassPointers. However, this is practically irrelevant, as 32-bit pointers are sufficient to address 4 GB and thus approximately 6 million classes. Even large Java applications rarely count more than 100,000 classes.

With Compact Object Headers activated in Java 25, class pointers are further compressed to just 22 bits, allowing approximately 4 million – still sufficient – classes to be addressed.

Support for uncompressed class pointers is to be removed in a future Java version. Accordingly, the option UseCompressedClassPointers has now been marked as deprecated.

There is no JEP for this change; it is listed in the bug tracker under JDK-8350753.

Various Permission Classes Deprecated for Removal

In Java 17, the Security Manager was marked as deprecated for removal. Since Java 24, the Security Manager can no longer be activated.

In Java 25, numerous ...Permission classes, which were only usable in connection with the Security Manager, have now also been marked as deprecated for removal.

You can read which classes are affected in detail in the bug tracker under JDK-8348967, JDK-8353641, JDK-8353642, and JDK-8353856.

Syntax Highlighting for Code Fragments

The javadoc tool has been extended with the command line option --syntax-highlight. If this option is specified when calling the javadoc command, the library Highlight.js is included in the generated documentation and the code in {@snippet} tags and HTML elements is color-coded accordingly.

There is no JEP for this change; it is listed in the bug tracker under JDK-8348282.

Keyboard Navigation

JavaDoc documentation generated with Java 25 can now be navigated using the keyboard:

• / focuses the search field in the top right.
• . focuses the filter field in the sidebar.
• Esc removes the focus from the search or filter field.
• With Tab and the arrow keys, you can navigate in the sidebar and the search results.

There is no JEP for this change; it is listed in the bug tracker under JDK-8350638.

Add Standard System Property Stdin.Encoding

The new system property stdin.encoding can be used to set the character encoding for reading System.in. If not explicitly specified – e.g., through -Dstdin.encoding=UTF-8 – the value is determined by the operating system and user environment.

Note that this setting is not automatically used, but must be explicitly read and applied by an application, e.g., when using InputStreamReader or Scanner.

There is no JEP for this change; it is listed in the bug tracker under JDK-8350703.

The Jwebserver Tool -D Command Line Option Now Accepts Directories Specified with a Relative Path

In Java 18, the so-called Simple Web Server was introduced – a rudimentary HTTP server that can be quickly started to serve static web pages.

For example, the following command serves the /tmp directory at IP address 127.0.0.100 and port 4444:

jwebserver -b 127.0.0.100 -p 4444 -d /tmpCode language: plaintext (plaintext)

Previously, an absolute path had to be specified (via the -d parameter) – which was cumbersome when wanting to share a directory via HTTP within the current project. From Java 25 onwards, a relative directory name can now be specified.

There is no JEP for this change; it is listed in the bug tracker under JDK-8355360.

Java.Io.File Treats the Empty Pathname as the Current User Directory

A java.io.File object created with new File("") previously led to undefined and inconsistent behavior when calling methods on this object. From Java 25 onwards, this creates a File object that represents the current directory.

This aligns the behavior of File with java.nio.Path – Path.of("") always created a representation of the current directory.

There is no JEP for this change; it is listed in the bug tracker under JDK-8024695.

Java.Io.File.Delete No Longer Deletes Read-Only Files on Windows

Previously, calling File.delete() on Windows could also delete files marked as “read-only”. From Java 25 onwards, such files will no longer be deleted, and delete() will return false accordingly.

The previous behavior can be restored with the system property -Djdk.io.File.allowDeleteReadOnlyFiles=true.

There is no JEP for this change; it is listed in the bug tracker under JDK-8355954.

Complete List of all Changes in Java 25

In this article, I have presented all JDK Enhancement Proposals (JEPs) as well as a selection of other changes without JEP that were implemented in Java 25. A complete list of all changes can be found in the Java 25 Release Notes.

Conclusion

Java 25 is once again a well-rounded LTS (long-term-support) release.

• With Scoped Values, the second feature from Project Loom has been finalized. It’s a shame that Structured Concurrency didn’t make it into this release – but thanks to the 6-month release cycle, we’d rather get a mature feature later than an immature one too early.
• Module Import Declarations make the import block more organized – it remains to be seen to what extent this will be adopted (outside of JShell and compact source files) – nowadays, the IDE primarily takes care of managing imports.
• Compact Source Files and Instance Main Methods allow us to write short test and demo programs more quickly. They are also intended to simplify learning the language for beginners.
• Flexible Constructor Bodies finally allow us to call code in constructors before calling super() or this(), making unsightly workarounds, e.g., for checking parameters before calling the super constructor, obsolete.
• Compact Object Headers, when activated, reduce the object header from 12 to 8 bytes, thereby reducing the memory footprint, especially for applications with many small objects.
• Generational Shenandoah speeds up applications that use the Shenandoah Garbage Collector. However, specific figures are not mentioned in the JEPs.
• Ahead-of-Time Command-Line Ergonomics simplify the creation of an AOT cache, and Ahead-of-Time Method Profiling also stores information about method calls in the AOT cache, which can lead to significant improvements in startup time as frequently called methods can be optimized immediately.

Further minor changes round off the LTS release as always. You can download Java 25 here.

Which Java 25 feature are you most excited about? Write it in the comments!

Java 24 has been released on March 18, 2025. You can download it here.

Java 24 contains … drum roll … exactly 24 JEPs – a new record after Java 11 (18 JEPs)! That sounds like a lot at first, but most of us will not be directly confronted with many of the changes in our day-to-day programming.

Here are my highlights:

• The Stream Gatherers API, which allows us to write our own intermediate stream operations, has been finalized.
• Synchronize Virtual Threads without Pinning: We can finally use synchronized around blocking code in virtual threads!
• Ahead-of-Time Class Loading & Linking significantly reduces the start time, particularly for short-lived Java programs.
• With Compact Object Headers, the object header can be shortened from (usually) 12 bytes to 8 bytes, thus reducing the memory requirement per object on the heap by 4 bytes. That is a significant overall saving for applications with millions of objects on the heap.

Stream Gatherers – JEP 485

The Stream API was introduced in Java 8 over ten years ago. Due to the somewhat limited selection of intermediate operations – filter, map, flatMap, mapMulti, distinct, sorted, peak, limit, skip, takeWhile, and dropWhile – there are loud calls in the Java community for additional operations such as window or fold.

But instead of implementing all these feature requests, the JDK developers decided on a different solution: they implemented an API with which both the JDK developers and all other developers can implement intermediate stream operations themselves.

This new API is called “Stream Gatherers.” It was first introduced as a preview version in Java 22 and went into a second preview round in Java 23 without any changes.

In Java 24, JDK Enhancement Proposal 485 finalizes the Stream Gatherers API – again without any changes.

For example, the following code shows how we can implement and use the intermediate stream operation “filter” as a stream gatherer. The short program displays all strings that are at least three characters long:

void main() {
  List<String> words = List.of("the", "be", "two", "of", "and", "a", "in", "that");

  List<String> list = words.stream()
      .gather(filtering(string -> string.length() >= 3))
      .toList();

  System.out.println(list);
}

private <T> Gatherer<T, Void, T> filtering(Predicate<T> predicate) {
  return Gatherer.of(Gatherer.Integrator.ofGreedy(
      (_, element, downstream) -> {
        if (predicate.test(element)) {
          return downstream.push(element);
        } else {
          return true;
        }
      }));
}Code language: Java (java)

What are the components of this program, and how do they work?

How do you implement more complex stream gatherers, and what are the limitations?

Which predefined stream gatherers does Java 24 provide?

You can find out all this in the main article about Stream Gatherers.

Synchronize Virtual Threads Without Pinning – JEP 491

Since its introduction in Java 21, Virtual Threads were “pinned” to their carrier thread when blocking code was called within a synchronized block, i.e., the carrier thread was blocked and could not serve any other virtual threads in the meantime. This could cause entire applications to freeze, as in the case of Netflix described here.

As of Java 24, this problem is a thing of the past. When blocking code is called within a synchronized block, the virtual thread is now detached from the carrier thread, which can then execute other virtual threads.

Why Were Virtual Threads “Pinned”?

Firstly, with so-called Legacy Stack Locking, the mark word in the object header was replaced by a pointer to a memory address on the thread stack when a synchronized block was entered. As the stack is moved to the heap when a virtual thread is unmounted and back to the stack when mounted – but possibly to the stack of another carrier thread – this memory address would have become invalid.

Lightweight Locking, activated by default since Java 23, solved this problem by not requiring any changes to the mark word.

Secondly, when a synchronized block is entered, the JVM remembers which platform thread is in the block, not which virtual thread. If the virtual thread is now unmounted from the carrier thread and another virtual thread is mounted on this carrier, then this other virtual thread could also enter the synchronized block.

Why does the JVM remember the platform thread and not the virtual thread? Quite simply, the JVM code is complex, and the JDK developers did not manage to adapt it in time for the release of Java 21.

Pinning When Executing Native Code

Native code (called via JNI or FFM-API) could also use pointers on the thread stack, which would become invalid after unmounting and mounting a virtual thread on another carrier thread. Therefore, when calling native code, a virtual thread is still pinned to its carrier thread.

That has not been changed by this JEP and will probably not change in the future.

The Diagnostic Property jdk.tracePinnedThreads Is Removed

With the system property jdk.tracePinnedThreads, we could configure the JVM to print a stack trace when a virtual thread was pinned to its carrier upon entering a synchronized block. As the printing happened within the synchronized block, the duration of the pinning was extended.

The property was removed without replacement in Java 24.

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

Java applications are highly flexible and performant:

• Classes can be loaded and unloaded dynamically.
• Dynamic compilation, optimization, and re-optimization make them run faster than C code.
• Reflection facilitates enterprise frameworks such as Jakarta EE and Spring Boot.

However, the JVM must read, parse, load, and link thousands of classes at startup, which can lead to long startup times, especially for large backend applications.

In Project Leyden, the JDK developers have long been working on solutions to carry out as many of these preparatory tasks as possible before an application is started. JDK Enhancement Proposal 483 introduces the first of these solutions in Java 24: Ahead-of-Time Class Loading & Linking.

In a preparatory phase, all classes required by the application are read, parsed, loaded, and linked, then saved in this state in a cache. When the application is started, these steps no longer need to be carried out; the application can access the loaded and linked classes directly via the cache.

You can find further details on how this works, a step-by-step guide to try it out yourself, and a comparison with AppCDS (Application Class Data Sharing) in the main article, Ahead-of-Time Class Loading & Linking.

New Preview and Experimental Features in Java 24

Java 24 comes with one new preview feature and two experimental features. 24.

These features are intended for testing and providing feedback. They should not be used in production code, as they can still change or – as in the case of String Templates – be completely removed again.

You must activate preview features in the Java compiler javac with --enable-preview --source 24. When starting a program with the java command, --enable-preview is sufficient.

You can activate experimental features at run-time using -XX:+UnlockExperimentalVMOptions.

Key Derivation Function API (Preview) – JEP 478

A key derivation function (KDF) is a method for deriving one or more new cryptographic keys from a secret value such as a password, a passphrase, or a cryptographic key.

For security providers to be able to implement and offer KDF algorithms and for us to be able to use them in applications, a standardized API is necessary.

Such an API is provided by JDK Enhancement Proposal 478: We can now load and execute key derivation functions via the new class javax.crypto.KDF.

The following sample code shows how to generate an AES key from a password or passphrase and a salt using the KDF algorithm “HKDF-SHA256”.

void main() throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
  // 1. Get the implementation of the specified KDF algorithm
  KDF hkdf = KDF.getInstance("HKDF-SHA256");

  // 2. Specify the derivation parameters
  AlgorithmParameterSpec params =
      HKDFParameterSpec.ofExtract()
          // 2.1. The password / passphrase
          .addIKM("the super secret passphrase".getBytes(StandardCharsets.UTF_8))
          // 2.2. The salt value
          .addSalt("the salt".getBytes(StandardCharsets.UTF_8))
          // 2.3. Optional application-specific information
          .thenExpand("my derived key".getBytes(StandardCharsets.UTF_8), 32);

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

  System.out.println("key = " + HexFormat.of().formatHex(key.getEncoded()));
}Code language: Java (java)

If you are wondering about the missing class declaration, missing imports, and the short void main() instead of the usual public static void main(String[] args) – you can find a description of these simplifications in the section Simple Source Files and Instance Main Methods.

If you save the source code shown above in the file KDFTest.java, you can execute it with Java 24 as follows:

java --enable-preview KDFTest.javaCode language: plaintext (plaintext)

In my case, for example, this leads to the following output:

key = 7ee15549ddce956194ca1d6df5aa34c1a1334d15c875e67ea67fb5850ee48b0cCode language: plaintext (plaintext)

You can then use this key as a session key for encrypted data transmission, for example.

The Key Derivation Function API will be finalized in Java 25.

Generational Shenandoah (Experimental) – JEP 404

Two new garbage collectors, ZGC and Shenandoah, were introduced in Java 15. Both promise extremely low pause times of less than 10 milliseconds.

At the time of their introduction, these GCs made no distinction between “old” and “new” objects. Therefore, they did not make use of the so-called “Weak Generational Hypothesis,” which states that most objects die again shortly after their creation and that those objects that have already reached a certain age will generally live even longer.

A “generational garbage collector” uses this hypothesis by dividing the heap into two logical areas: a “young generation” and an “old generation.” New objects are created in the young generation, and once they have survived a few GC cycles, they are moved to the old generation. As there is a high probability that the objects in the old generation will live longer, the garbage collector can increase the performance of an application by cleaning up the old generation less frequently.

Java 21 introduced a “Generational Mode” for ZGC, which has been activated by default since Java 23.

Initially, a “Generational Mode” mode was also planned for Shenandoah in Java 21, but the Shenandoah team withdrew the JEP shortly before its release because the implementation was not yet fully finished.

The time has finally come: Java 24 introduces a “Generational Mode” for Shenandoah. This mode is currently still being tested and can be activated as follows:

-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational

The changes are described in JDK Enhancement Proposal 404 – albeit quite superficially. If you are interested in how a generational garbage collector works, I recommend reading the detailed JEP 439 (Generational ZGC).

Compact Object Headers (Experimental) – JEP 450

The Java object header is currently 12 bytes in size (or 16 bytes if Compressed Class Pointers are switched off. To reduce the memory requirements of Java applications, the JDK developers are working (within Project Lilliput) on ways to compress the header to 8 bytes – and in the next step to 4 bytes.

The first promising result from Project Lilliput was presented in Java 24: JDK Enhancement Proposal 450 allows the object header to be compressed to 8 bytes (currently in “experimental” status).

How did the JDK developers achieve this?

Status Quo

A 12-byte object header consists of a 64-bit Mark Word and a 32-bit Class Word:

The Mark Word contains:

• 27 unused bits (25 at the beginning and one each before and after the “age tag”),
• a 31-bit long identity hash code,
• 4 bits in which the garbage collector stores the age of an object,
• 2 “tag bits” that indicate whether and how the object is locked.

The Class Word contains:

• a 32-bit pointer to the so-called klass data structure, in which the information about the class of which the object is an instance is stored.

Compressing the Object Header

The Mark Word contains 27 unused bits. That means that only 69 of the 96 bits are needed. To get to 64 bits, we must somehow save five bits. The result is as follows:

We now have a 64-bit header that is no longer divided into Mark Word and Class Word. The header contains:

• a class pointer compressed from 32 bits to 22 bits,
• the 31-bit Identity Hash Code (unchanged),
• 4 bits reserved for Project Valhalla (new),
• 4 bits for the age of the object (unchanged),
• 1 bit for the so-called “Self Forwarded Tag” (new),
• 2 tag bits (unchanged).

The class pointer has therefore been reduced by 10 bits. As we only had to save five bits, there are now five additional bits available. Four of these were reserved for Project Valhalla, and the new “Self Forwarded Tag” is stored in one bit.

You can find out how the JDK developers managed to compress the class pointer from 32 bits to 22 bits and what the “Self Forwarded Tag” is in the main article on Compact Object Headers.

Compact Object Headers are still in the experimental stage in Java 24 and must be activated with the following VM option:

-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders

Resubmitted Preview and Incubator Features

Seven preview and incubator JEPs were resubmitted in Java 24 – four without changes compared to Java 23, one with changes only in the terminology and two with minor modifications. You can find out what these are in the following sections.

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

Pattern matching with instanceof was introduced in Java 16 and pattern matching with switch in Java 21.

The following switch statement, for example, checks whether the object obj is a String of at least five characters and then prints it converted to upper case. However, if the object is an Integer, the number is printed squared:

switch (obj) {
  case String s when s.length() >= 5 -> System.out.println(s.toUpperCase());
  case Integer i                     -> System.out.println(i * i);
  case null, default                 -> System.out.println(obj);
}Code language: Java (java)

So far, we could only match objects with patterns, not primitive data types like int, long, or double.

However, what we have always been able to do in a switch (though not in modern arrow notation) was, for example, to compare an int variable with constants:

int code = . . .
switch (code) {
  case 200 -> System.out.println("OK");
  case 400 -> System.out.println("Bad Request");
  case 404 -> System.out.println("Not Found");
  . . .
}Code language: Java (java)

But beware: so far, this has only worked with the primitive data types byte, short, char, and int – but not with long,float, double, and boolean.

With “Primitive Types in Patterns, instanceof, and switch” – first introduced in Java 23 by JDK Enhancement Proposal 455 and re-introduced in Java 24 by JDK Enhancement Proposal 488 without any changes – two things will change:

1. In pattern matching with instanceof and switch, we can also use primitive types.
2. In switch, we can use all primitive types, including long, float, double – and even boolean.

However, pattern matching with primitive types differs from pattern matching with reference types:

• In pattern matching with reference types, we check whether an object is an instance of a specific type (class or interface) or an instance of a type derived directly or indirectly from this type. For example, a variable of type Integer would match the pattern Integer i but also the patterns Number n, Object o, or even Comparable c or Serializable s.
• In pattern matching with primitive types, on the other hand, we check whether a variable can be stored in a type without any loss of precision.

This may sound complicated at first, but it can be easily explained using an example:

int i = . . .
if (i instanceof byte b) {
  . . .
}Code language: Java (java)

The code should be read as follows: If the content of the int variable i can also be represented in a byte, then the variable matches the pattern and is made available in the “then” block in the byte variable b.

For example, the instanceof check above would result in true for a = 50 but false for a = 500, as a byte can only store values from -128 to +127.

Here is a second example:

double d = . . .
if (d instanceof float f) {
  . . .
}Code language: Java (java)

This means that if the content of the double variable d can be stored in a float without loss of precision, then the variable matches the pattern.

For example, the test would result in true for d = 1.5 but false for d = Math.PI, as Math.PI has more decimal places than float can accommodate (to put it simply).

We can also use primitive type patterns in switch:

double value = ...
switch (value) {
  case byte   b -> System.out.println(value + " instanceof byte:   " + b);
  case short  s -> System.out.println(value + " instanceof short:  " + s);
  case char   c -> System.out.println(value + " instanceof char:   " + c);
  case int    i -> System.out.println(value + " instanceof int:    " + i);
  case long   l -> System.out.println(value + " instanceof long:   " + l);
  case float  f -> System.out.println(value + " instanceof float:  " + f);
  case double d -> System.out.println(value + " instanceof double: " + d);
}Code language: Java (java)

For value = 5, for example, the pattern byte b would match, for value = 500 the pattern short s, for value = 5000000 the pattern int i and for value = 1.5 the pattern float f.

For example:

• For value = 5, the pattern byte b would match.
• For value = 500, the pattern short s would match.
• For value = 5000000, the pattern int i would match.
• And for value = 1.5, the pattern float f would match.

Even with switch with primitive types, we must observe the principle of dominating and dominated types as well as the completeness check.

You can find more about this and other examples in the main article Primitive types in patterns, instanceof and switch.

Module Import Declarations (Second Preview) – JEP 494

We have always been able to import individual classes or entire packages with the import statement.

With import module, first introduced as a preview feature in Java 23 by JDK Enhancement Proposal 476, we can now also import entire modules – and thus directly use the classes of all packages exported by that module.

In the following example, we import the module java.base and can therefore use the classes List, Map, Stream and Collectors without having to import them individually:

import module java.base;

public static Map<Character, List<String>> groupByFirstLetter(String... values) {
  return Stream.of(values).collect(
      Collectors.groupingBy(s -> Character.toUpperCase(s.charAt(0))));
}Code language: Java (java)

Resolving Ambiguous Class Names

If a class name exists in several imported modules, e.g., List in the module java.base and in the module java.desktop, then the compiler would not know which class you mean, as in the following example:

import module java.base;
import module java.desktop;

. . .
List list = new ArrayList();  // Compiler error: "reference to List is ambiguous"
. . .Code language: Java (java)

You can resolve this ambiguity by importing the desired class:

import module java.base;
import module java.desktop;

import java.util.List;  // ⟵ This resolves the ambiguity

. . .
List list = new ArrayList();
. . .Code language: Java (java)

What was not yet possible in Java 23 and was added in Java 24 in the second preview of this feature via JDK Enhancement Proposal 494 is the possibility of resolving the ambiguity using a package import, as follows:

import module java.base;
import module java.desktop;

import java.util.*;  // ⟵ This resolves the ambiguity (since Java 24)

. . .
List list = new ArrayList();
. . .Code language: Java (java)

Transitive Imports

If an imported module imports another module transitively, then you can also use all classes of the exported packages of the transitively imported module without explicit imports.

You can find an example in the main article on module imports.

However, in Java 23, this feature led to confusion in the Java community:

When importing the module java.se (an aggregator module that defines dependencies on all modules of the Java Standard Edition “Java SE”), the module java.base was not imported. This was due to the fact that Java modules were previously not allowed to define a transitive dependency on java.base.

JDK Enhancement Proposal 494 removes this restriction in the language specification and marks the dependency of java.se on java.base as transitive so that all classes from the java.base module are now also available via import module java.se.

Adjustments to JShell and Simple Source Files

JShell and Simple Source Files automatically import the java.base module if preview features are activated.

You can find further examples of resolving ambiguous class names and transitive module dependencies in the main article in the main article, Importing Modules in Java: Module Import Declarations.

Flexible Constructor Bodies (Third Preview) – JEP 492

Previously, we were not allowed to execute code in constructors before calling super() or this(). For example, if we wanted to check a parameter before calling super(), this was only possible by calling a static method within the parentheses of the super(...) call:

public class ChildClass extends SuperClass {
  public ChildClass(String parameter) {
    super(verifyParameter(parameter));
  }

  private static String verifyParameter(String parameter) {
    if (parameter == null || parameter.isEmpty()) {
      throw new IllegalArgumentException();
    }
    return parameter;
  }
}Code language: Java (java)

However, this workaround quickly becomes confusing if there are multiple parameters.

Using “Flexible Constructor Bodies” – first introduced in Java 22 as a preview feature under the name “Statements before super(…)” by JDK Enhancement Proposal 447 – you can rewrite the code as follows:

public class ChildClass extends SuperClass {
  public ChildClass(String parameter) {
    if (parameter == null || parameter.isEmpty()) {
      throw new IllegalArgumentException();
    }
    super(parameter);
  }
}
Code language: Java (java)

This allowed read and write access to the constructor’s parameters and variables before calling super(…), but not to the fields of the class.

In Java 23, the feature was renamed “Flexible Constructor Bodies” via JDK Enhancement Proposal 482. The restriction mentioned in the previous paragraph has been relaxed so that we can now initialize the classes’ fields before calling the super constructor.

This is particularly helpful in cases where the super constructor calls methods overwritten in the derived class, where they read the classes’ fields.

Here is an example:

public class SuperClass {
  public SuperClass() {
    logCreation();
  }

  protected void logCreation() {
    System.out.println("SuperClass created");
  }
}

public class ChildClass extends SuperClass {
  private final String parameter;

  public ChildClass(String parameter) {
    this.parameter = parameter;
  }

  @Override
  protected void logCreation() {
    System.out.println("ChildClass created, parameter = " + parameter);
  }
}Code language: Java (java)

What would be the output when creating a new ChildClass object, e.g., with new ChildClass("foo")?

We would probably expect the following output:

ChildClass created, parameter = fooCode language: plaintext (plaintext)

However, we actually get to see the following (null instead of foo):

ChildClass created, parameter = nullCode language: plaintext (plaintext)

Why is that?

The ChildClass constructor first calls super() (this call is inserted by the compiler at the beginning of the ChildClass constructor). The SuperClass constructor then calls the logCreation() method, which we overwrote in ChildClass. However, the field parameter has not yet been assigned at this point and is, therefore, still null.

Irrespective of the question of whether we should call non-final, i.e. overridable, methods in the constructor at all, we can solve the problem in Java 23 by modifying the ChildClass constructor as follows:

public ChildClass(String parameter) {
  this.parameter = parameter;  // ⟵ First assign the parameter,
  super();                     // ⟵ then call super()
}Code language: Java (java)

This means that the super constructor (and, therefore, also the logCreation() method) is only called after the parameter field has been assigned. Accordingly, logCreation() will display the initialized field and no longer null.

In Java 24, “Flexible Constructor Bodies” are resubmitted by JDK Enhancement Proposal 492 without any changes – the JEP authors just slightly revised the wording. Flexible Constructor Bodies will be finalized in Java 25.

You can read about other use cases and particularities to consider in the main article, Flexible Constructor Bodies in Java: Executing Code Before super().

Structured Concurrency (Fourth Preview) – JEP 499

Structured Concurrency is a modern approach for dividing tasks into smaller parts that can be executed in parallel in virtual threads within a clearly recognizable source code block.

The start and end of all subtasks are clearly visible, and as soon as the structured concurrency code section is left, the programming model ensures that all threads have been successfully or erroneously completed or canceled and that the status of all subtasks is known.

Structured Concurrency blocks can be nested within each other, as the following graphic shows:

We can use various strategies to determine whether, for example, a subtask’s successful or incorrect completion should lead to the cancellation of all other subtasks and the successful or incorrect completion of the overall task.

The following code example shows how an application reads weather information from three sources in parallel and, when the first answer is received, cancels the other requests and returns the response:

WeatherResponse getWeatherFast(Location location)
    throws InterruptedException, ExecutionException {
  try (var scope = new ShutdownOnSuccess<AddressVerificationResponse>()) {
    scope.fork(() -> weatherService.readFromStation1(location));
    scope.fork(() -> weatherService.readFromStation2(location));
    scope.fork(() -> weatherService.readFromStation3(location));

    scope.join();

    return scope.result();
  }
}Code language: Java (java)

Without structured concurrency, this task would require significantly longer and more complex code, which would also be more error-prone.

You can find a detailed description and numerous other examples in the main article on Structured Concurrency.

Structured Concurrency was introduced in Java 21 as a preview feature and resubmitted in Java 22 and Java 23 without any changes. In Java 24, the feature will be resubmitted via JDK Enhancement Proposal 499 without any changes.

Scoped Values (Fourth Preview) – JEP 487

With scoped values, we can pass values to direct or indirect method calls without defining them as method parameters and, potentially, passing them through a lengthy call chain.

The classic example is the user logged into a web application:

Instead of passing a user object to all methods within the web application as a parameter, we can store the user in a Scoped Value. All methods invoked within the same request processing thread can then retrieve the user object from this Scoped Value.

Does that sound familiar?

That’s because we have previously implemented such use cases with ThreadLocal variables. However, Scoped Values have a range of advantages, which I describe in detail in the main article on Scoped Values.

How do you implement such a Scoped Value as Java code?

Once we have authenticated a user, we store them in a Scoped Value using ScopedValue.where() and then call up the application code in the context of this Scoped Value with run():

public class Server {
  public final static ScopedValue<User> LOGGED_IN_USER = ScopedValue.newInstance();

  private void serve(Request request) {
    . . .
    User loggedInUser = authenticateUser(request);
    ScopedValue.where(LOGGED_IN_USER, loggedInUser)
               .run(() -> restAdapter.processRequest(request));
    . . .
  }
}Code language: Java (java)

The method called within the run() method – and, in turn, every method called directly or indirectly by this method – can now access the User object via ScopedValue.get():

public class ApplicationService {
  public void doSomethingSmart() {
    User loggedInUser = Server.LOGGED_IN_USER.get();
    . . .
  }
}Code language: Java (java)

Scoped values were first introduced as a preview feature in Java 21.

In Java 23, the generic and functional interface ScopedValue.CallableOp was introduced to make exception handling type-safe – and therefore more readable and maintainable – when calling ScopedValue.call() and ScopedValue.callWhere().

In Java 24, the methods ScopedValue.callWhere() and ScopedValue.runWhere() were removed via JDK Enhancement Proposal 487 to make the interface completely “fluid.” These convenience methods were defined as follows in Java 23:

public static <T, R, X extends Throwable> R callWhere(
    ScopedValue<T> key, T value, CallableOp<? extends R, X> op) throws X {
  return where(key, value).call(op);
}

public static <T> void runWhere(ScopedValue<T> key, T value, Runnable op) {
  where(key, value).run(op);
}Code language: Java (java)

Instead of callWhere() or runWhere(), you must now call where() followed by call() or run().

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

When Java beginners write their first Java program, it usually looks something like this:

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello world!");
  }
}Code language: Java (java)

Multiple concepts are introduced here simultaneously: classes, visibility modifiers, static, and (unused) method arguments. This can quickly lead to cognitive overload.

Wouldn’t it be nice if we could express the same instructions as follows?

void main() {
  println("Hello world!");
}Code language: Java (java)

That is precisely what Simple Source Files and Instance Main Methods make possible!

• A simple source file is a .java file that does not contain an explicit class specification. Instead, the compiler generates a so-called implicit class.
• An instance main method does not have to be public or static, nor does it have to have parameters.

In addition, the new class java.io.IO with the static methods print(), println(), and readln() is introduced. This class is located in the java.base module, which is automatically imported into simple source files (see section Module Import Declarations). That means that println() can be used without a preceding System.out and without an import statement.

You can find further details, examples, restrictions, and constraints for overloaded main() methods in the main article on the Java main() method.

Feature History

This feature was first published in Java 21 as “Unnamed Classes and Instance Main Methods.” The concept of “implicitly declared classes” was then introduced in Java 22, and the java.io.IO class was added in Java 23.

In Java 24, the term “Simple Source Files” was finally introduced by JDK Enhancement Proposal 495, and the feature was renamed “Simple Source Files and Instance Main Methods.”

Vector API (Ninth Incubator) – JEP 489

The Vector API is a new API that we can use to perform mathematical vector calculations such as the following:

The characteristic feature of the new API is that these calculations are optimized for vector instructions of modern CPUs. That means these calculations can be carried out (up to a certain vector size) in a single CPU cycle.

The Vector API is submitted as an incubator feature for the ninth time via JDK Enhancement Proposal 489. It will remain an incubator feature until the necessary functions from Project Valhalla have reached the preview stage.

As soon as the Vector API is promoted to a preview feature, I will describe it in more detail.

Deprecations, Warnings, Deletions

In Java 24, some functionalities were deprecated, some functions lead to run-time warnings, and others have been permanently removed. Discover which functionalities are affected in the following sections.

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

The sun.misc.Unsafe class introduced in Java 1.4 (over 20 years ago) has been a powerful but dangerous tool for directly accessing the working memory (both heap and native memory, i.e., memory not managed by the garbage collector).

Developers were never supposed to use this class directly. However, on the one hand, it could not be prevented (due to a module system that did not yet exist at the time); on the other hand, we had no alternatives available.

But today, we have alternatives:

Since Java 9, VarHandles for accessing the Java heap and, since Java 22, the Foreign Function & Memory API for accessing native memory have been available as secure replacements.

As a secure replacement, VarHandles have been available for accessing the Java heap since Java 9, and the Foreign Function & Memory API has been available for accessing native memory since Java 22.

For this reason, the memory access methods from sun.misc.Unsafe are being removed step by step:

1. In the first step, the corresponding methods were marked as deprecated for removal in Java 23.
2. In Java 24, as defined by JDK Enhancement Proposal 498, the use of these methods will lead to warnings at run-time.
3. In Java 26, these methods are expected to throw an UnsupportedOperationException.
4. And in a later, as yet undetermined release, the methods will be completely removed.

What does that mean for us?

In the medium term, we need to check our applications to see whether they use the affected methods from java.misc.Unsafe and, if so, switch to the safer alternatives VarHandles and the Foreign Function & Memory API.

We can deactivate the warnings in Java 24 using the VM setting --sun-misc-unsafe-memory-access=allow. However, I do not recommend this, as we will have to make the change sooner or later anyway if we want to upgrade to new Java versions. In addition, this option will no longer be available at the next level, i.e., probably in Java 26.

The following values are available for this VM option --sun-misc-unsafe-memory-access:

• allow – switches off the warnings, as just explained.
• warn – This is the default setting in Java 24, i.e. the use of the methods is still permitted but leads to a warning at run-time when such a method is invoked for the first time.
• debug – leads to warnings and the output of a stack trace with every call (i.e., not just the first).
• deny – leads to an UnsupportedOperationException when such a method is called. This will probably be the default setting in Java 26.

You can find a complete list of the affected methods in the section sun.misc.Unsafe memory-access methods and their replacements of JEP 471, which deprecated the methods in Java 23.

Permanently Disable the Security Manager – JEP 486

The “Security Manager,” which was initially developed to secure Java applets and is almost irrelevant for today’s Java applications, was marked as “deprecated for removal” in Java 17. The intention was to allocate the resources used to maintain the Security Manager to more important projects.

In Java 24, the Security Manager can no longer be activated, either when starting an application or during run-time. The attempt leads to an error message.

The deactivation of the Security Manager is documented in JDK Enhancement Proposal 486.

The Security Manager will be completely removed in a future Java release.

ZGC: Remove the Non-Generational Mode – JEP 490

Java 21 introduces the “Generational Mode” for the Z Garbage Collector (ZGC). This mode divides objects into short-lived (young generation) and long-lived (old generation) objects to optimize garbage collection performance.

Since Java 23, this mode is activated by default when ZGC is selected. However, we could still deactivate it using the VM option -XX:+UseZGC -XX:-ZGenerational.

To avoid maintaining two modes, JDK Enhancement Proposal 490 removes the “Non-Generational Mode” in Java 24.

The VM option -XX:-ZGenerational no longer has any effect and leads to a warning. It will be removed in a future Java version.

Remove the Windows 32-bit x86 Port – JEP 479

In Java 21, the 32-bit Java port for Windows was marked as “deprecated for removal.” There was hardly any need for this version, maintenance was expensive, and, for example, Virtual Threads were not even implemented in this port.

Consequently, the 32-bit port for Windows is completely removed in Java 24 by JDK Enhancement Proposal 479.

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

With the removal of the 32-bit port for Windows (see previous section), the 32-bit port for Linux is the last remaining 32-bit port – and thus the last port for which the JDK developers must implement fallbacks for the 32-bit architecture.

In order to completely eliminate this extra effort in the future, JDK Enhancement Proposal 501 also marks the Linux 32-bit port as “deprecated for removal.”

This port will also be removed in a future Java version.

Other Changes in Java 24

We won’t encounter all the features of the new Java in everyday programming. In this chapter, you will find changes that are only relevant for specific use cases. However, as an advanced Java developer, you should have at least heard of these changes.

Class-File API – JEP 484

With the Class-File API, Java 24 contains an official API for reading and writing compiled Java bytecode (i.e. .class files) from Java code.

The Class-File API replaces the bytecode manipulation framework ASM, which has been widely used in the JDK. The reason for the in-house development is the fast JDK release cycle and the fact that ASM always lags behind the current Java version by at least one version, i.e. the ASM version contained in a current JDK can only handle .class files from the previous Java version at most.

With the release of the Class-File API, this cyclical dependency no longer exists, and Java 24 can now also inspect and modify .class files created by Java 24.

The Class File API was first introduced as a preview feature in Java 22 and sent into a second preview round in Java 23 with minor improvements.

In Java 24, JDK Enhancement Proposal 484 finalizes the new API with minor improvements.

Since most Java developers only work with the Class File API indirectly via tools and will never call it directly, I will not provide a detailed description of the interface here. If you are interested, you can find all the details in JEP 484.

Prepare to Restrict the Use of JNI – JEP 472

Any interaction between Java and native code is risky, as it can lead to undefined behavior and crashes (C code can write beyond the limits of an array, for example). This applies to both the Java Native Interface (JNI) and the Foreign Function & Memory API (FFM-API), which is intended to replace JNI in the long term.

Status Quo

In the FFM API, potentially dangerous methods were classified as “restricted” from the outset, and their use had to be explicitly permitted via the VM option --enable-native-access. Otherwise, an IllegalCallerException was triggered at run-time.

That does not mean that using these methods is discouraged, but merely that one should be aware of the use of potentially dangerous functions – and that they must be explicitly permitted accordingly.

Expansion to JNI in Java 24

Due to JDK Enhancement Proposal 472, using corresponding JNI methods in Java 24 will lead to run-time warnings. These warnings can be prevented using the VM option --enable-native-access, as was previously the case with exceptions in the FFM API.

How exactly does --enable-native-access work?

You can either allow unrestricted access to native code for the entire application:

java --enable-native-access=ALL-UNNAMED ...

Or, better, you only allow native access to certain modules:

java --enable-native-access=MODUL1,MODUL2,MODUL3,... ...

Without further adjustment, without explicit access permission, JNI and FFM-API would now behave differently: JNI would issue a warning, and the FFM API would throw an IllegalCallerException.

Adaptation of the FFM API

For consistency reasons, the JDK developers decided to soften the behavior of the FFM-API for the time being and to have the FFM-API also issue warnings by default instead of triggering exceptions.

Configuration

This behavior can be adapted – uniformly for both APIs with the command line parameter --illegal-native-access. The parameter offers the following options:

The deny mode will become the default setting in a future release; then, both JNI and FFM-API will throw an IllegalCallerException by default.

In a later version, the --illegal-native-access parameter will be removed, and only the deny mode will remain.

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

Future quantum computers threaten traditional cryptographic algorithms such as RSA and Diffie-Hellman. The use of ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism – the link leads to the description of the mechanism on the website of the National Institute of Standards and Technology) should make it possible to exchange keys securely even in the age of quantum computers.

The following example shows how …

• the recipient generates an ML-KEM key pair,
• the sender generates a secret session key by key encapsulation with the recipient’s public key and encapsulates it
• and the recipient decapsulates the session key again.

The sender and receiver can then exchange messages securely using the quantum-safe session key.

void main() throws GeneralSecurityException {
  // Step 1 (Receiver): Create a ML-KEM public/private key pair:
  KeyPairGenerator generator = KeyPairGenerator.getInstance("ML-KEM");
  KeyPair keyPair = generator.generateKeyPair();

  PublicKey receiverPublicKey = keyPair.getPublic();
  PrivateKey receiverPrivateKey = keyPair.getPrivate();

  // Step 2 (Sender, has the receiver's public key):
  // Create a session key and encapsulate it:
  KEM kem = KEM.getInstance("ML-KEM");
  KEM.Encapsulator encapsulator = kem.newEncapsulator(receiverPublicKey);
  KEM.Encapsulated encapsulated = encapsulator.encapsulate();

  SecretKey sessionKey = encapsulated.key();
  System.out.println(HexFormat.of().formatHex(sessionKey.getEncoded()));
  
  byte[] keyEncapsulationMessage = encapsulated.encapsulation();

  // Step 3 (Receiver, has the sender's key encapsulation message):
  // Decapsulate the session key:
  KEM kr = KEM.getInstance("ML-KEM");
  KEM.Decapsulator decapsulator = kr.newDecapsulator(receiverPrivateKey);
  
  SecretKey decapsulatedSessionKey = decapsulator.decapsulate(keyEncapsulationMessage);
  System.out.println(HexFormat.of().formatHex(decapsulatedSessionKey.getEncoded()));

  // Now sender and receiver can exchange messages
  // using the securely transmitted session key.
  // . . .
}Code language: Java (java)

When I start the program, I get the following output, which proves that the encapsulated and decapsulated session keys match:

7fac6ccf466d3ce0412cb8080280bb3c8cfb2fca630042aee2bf17a213ca82fe
7fac6ccf466d3ce0412cb8080280bb3c8cfb2fca630042aee2bf17a213ca82feCode language: plaintext (plaintext)

JDK Enhancement Proposal 496 describes the implementation of the quantum-safe ML-KEM method in the JDK. You will also find further examples there.

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

Analogous to the ML-KEM method described in the previous section, the ML-DSA method (Module-Lattice-Based Digital Signature Algorithm – this link also leads to the National Institute of Standards and Technology), which is also quantum-safe, is added to the JDK.

The following example shows how …

• the sender generates an ML-DSA key pair,
• the sender signs his message with their private key,
• and the recipient verifies the signature with the sender’s public key.

The recipient can thus ensure that the message actually from the sender and has not been modified en route.

import java.security.Signature;

void main() throws GeneralSecurityException {
  // Step 1 (Sender): Create a ML-KEM public/private key pair:
  KeyPairGenerator generator = KeyPairGenerator.getInstance("ML-DSA");
  KeyPair keyPair = generator.generateKeyPair();

  PublicKey senderPublicKey = keyPair.getPublic();
  PrivateKey senderPrivateKey = keyPair.getPrivate();

  // Step 2 (Sender): Sign a message using the private key:
  byte[] message = "Roses bloom nightly.".getBytes(StandardCharsets.UTF_8);
  Signature signer = Signature.getInstance("ML-DSA");
  signer.initSign(senderPrivateKey);
  signer.update(message);
  byte[] signature = signer.sign();

  // Step 3 (Receiver): Verify the message using the sender's public key:
  Signature signatureVerifier = Signature.getInstance("ML-DSA");
  signatureVerifier.initVerify(senderPublicKey);
  signatureVerifier.update(message);
  boolean verified = signatureVerifier.verify(signature);
  
  . . .
}Code language: Java (java)

JDK Enhancement Proposal 497 describes the implementation of the quantum-safe ML-DSA procedure in the JDK.

Linking Run-Time Images without JMODs – JEP 493

A JDK installation consists of two components:

• a run-time image (the executable Java system)
• and a set of Java module files in the jmod directory.

However, the Java modules are also contained in the run-time image, in the lib/modules file.

Why this duplication?

The lib/modules file is used when running a Java application; the module files in the jmod directory are required by the jlink tool to generate a custom run-time image.

JDK Enhancement Proposal 493 will enable distributors to build a JDK without jmod files; the jlink tool will then extract the module information from the run-time image.

This will reduce the size of a JDK by around 25% – this is particularly relevant in the cloud environment, where increased memory requirements and higher traffic (due to the transfer of images) lead to higher costs.

The new option is not activated by default; JDK providers must proactively opt for this option when generating their JDKs.

In a future Java version, the option might be on by default.

Late Barrier Expansion for G1 – JEP 475

To understand this JEP, you first need to know what “barrier” and “expansion” mean.

Garbage Collector Barrier

In the context of garbage collection, a “barrier” refers to a piece of code that is executed before and/or after accessing Java objects.

For example, write barriers are used to trace which references exist from objects in the old generation to objects in the young generation, so that the young generation can be cleaned up without having to scan the entire old generation each time.

And, if the garbage collector has moved an object in the heap during a defragmentation phase, a read barrier ensures that the pointer to this object is updated when it is accessed.

The JVM automatically inserts these barriers into the machine code when it loads a Java program.

Bytecode Expansion

When the Java compiler compiles a Java program, it produces platform-independent bytecode. When the JVM starts the Java application, it converts this bytecode into highly optimized machine code.

For example, methods can be inlined, i.e., each method invocation gets replaced with a copy of the method’s code – this saves the overhead of calling the method. Also, loops can be unrolled, i.e., a loop is replaced by repeating the same machine code several times to eliminate the overhead of checking the terminal condition.

Due to this and other optimizations, the machine code usually occupies more memory than the bytecode. This process is, therefore, also referred to as “bytecode expansion” or just “expansion.”

Barrier Expansion – Status Quo

G1 is currently working with an “Early Barrier Expansion”:

The barrier code is provided in a platform-independent intermediate stage between bytecode and machine code, the so-called “Intermediate Representation” (IR).

The application byte code is also first converted into the “Intermediate Representation” and then combined with the Barrier IR code.

Then, over several stages, the combined IR code is optimized and translated into machine code:

This has two advantages:

• Since the barrier code is available in the platform-independent intermediate representation, it can be used on all platforms without any adjustments.
• The compiler can optimize the entire code, i.e., the barrier code can be optimized in the context of the application code.

However, early expansion has two significant disadvantages:

• The compiler must compile more IR code (application and barrier code).
• The garbage collector developers cannot foresee how the compiler optimizes the barrier code and, therefore, can often not reproduce potential errors.

The JDK developers decided that the disadvantages outweighed the advantages and, therefore, implemented “Late Barrier Expansion” via JDK Enhancement Proposal 475.

Late Barrier Expansion

With “Late Barrier Expansion,” the barrier code is not implemented as IR code but as an already optimized machine code. This optimized code is integrated into the application’s machine code after the application code has been compiled and optimized:

As the compiler now has to optimize less code, the JDK developers have measured that applications are about 10-20% faster!

The Z Garbage Collector (ZGC), by the way, has been working with Late Barrier Expansion since its introduction in Java 15.

Deprecate LockingMode Option, along with LM_LEGACY and LM_MONITOR

In Java 21, a new, experimental “Lightweight Locking” mode was introduced for object monitor locking (the mechanism for locking a critical area for other threads). This mode could be activated via the VM option -XX:LockingMode=2, instead of the “Stack Locking” mode previously used by default.

The following locking modes have since been selectable:

• -XX:LockingMode=0 – Exclusively heavyweight monitor objects (LM_MONITOR)
• -XX:LockingMode=1 – Stack Locking + monitor objects for contention (LM_LEGACY)
• -XX:LockingMode=2 – Lightweight Locking + monitor objects for contention (LM_LIGHTWEIGHT)

In Java 22, the experimental LM_LIGHTWEIGHT option was promoted to a productive option.

Lightweight Locking then became the new default mode in Java 23.

In Java 24, the VM option -XX:LockingMode and the selectable modes LM_MONITOR and LM_LEGACY, as well as the Stack Locking mechanism, are marked as “deprecated.”

The “heavyweight monitor objects” mechanism itself is not “deprecated”, but should no longer be selected via -XX:LockingMode=0, but – as before Java 21 – via the VM option -XX:+UseHeavyMonitors.

In Java 26, -XX:LockingMode should no longer have any effect, and in Java 27, the option will be completely removed.

(No JDK Enhancement Proposal exists for this change; it is listed in the bug tracker under JDK-8334299).

Support for Unicode 16.0

Java 24 raises Unicode support to version 16.0.

Why is this relevant?

All character-processing classes, such as String and Character, must be able to handle the characters and code blocks introduced in the new Unicode version.

You can find an example in the Unicode 10 section of the article on Java 11.

(No JDK Enhancement Proposal exists for this change; it is listed in the bug tracker under JDK-8319993).

Complete List of All Changes in Java 24

In this article, I have presented all JDK Enhancement Proposals (JEPs) and a selection of other non-JEP changes implemented in Java 24. You can find a complete list of all changes in the Java 24 Release Notes.

Conclusion

Wow – what a comprehensive release!

So that’s it, the 24 JDK Enhancement Proposals and two minor changes from the release notes. Here is a summary:

• With the Stream Gatherers API, we can write our own intermediate stream operations.
• We can now use synchronized around blocking calls without pinning a Virtual Thread to its carrier.
• With Ahead-of-Time Class Loading & Linking, the logical evolution of Class Data Sharing, applications start up to 42% faster (according to the JDK developers).
• With the Key Derivation Function API and quantum-safe encryption methods, Java has become even more secure.
• The Gargabe Collectors Shenandoah and G1 have been optimized: Shenandoah now has a “Generational Mode,” and in G1, the “Early Barrier Expansion” has been turned into a “Late Barrier Expansion.” In ZGC, the deprecated “Non-Generational Mode” has been removed.
• Compact Object Headers shorten the headers of each Java object by four bytes, thus significantly reducing the memory footprint of the entire application.
• Primitive Type Patterns, Flexible Constructor Bodies, Structured Concurrency, and the Vector API have been resubmitted as preview or incubator features without changes.
• Implicitly Declared Classes and Instance Main Methods has been renamed Simple Source Files and Instance Main Methods.
• When using import module, we can now resolve ambiguities with a package import. Importing the java.se module now makes the classes exported by the java.base module available without explicit imports.
• The convenience methods ScopedValues.runWhere() and callWhere() have been removed in the interests of a “Fluent API.”
• The use of memory access methods in sun.misc.Unsafe leads to run-time warnings.
• The Security Manager has been switched off.
• The 32-bit Windows version of Java has been removed, and the 32-bit Linux version has been deprecated.
• The finalized Class-File API replaces the byte code manipulation framework ASM.
• Using potentially unsafe JNI methods leads to warnings unless they were explicitly permitted at the start of the application.
• JDK images can now be provided without jmod files, which reduces their size by approximately 25%.
• The VM option -XX:LockingMode has been deprecated.
• Unicode support is upgraded to version 16.0.

You can download Java 24 here. If you had previously installed a preview version: you need at least build 26 to be able to compile all the source code shown in this article.

Which of the new Java 24 features do you find the most exciting? Which feature do you miss? Share your opinion in the comments!

Java 23 has been released on September 17, 2024. You can download it here.

The highlights of Java 23:

• Markdown Documentation Comments: Finally, we are allowed to write JavaDoc with Markdown.
• Match variables against primitive types with Primitive Types in Patterns, instanceof, and switch (Preview).
• Import entire modules with Module Import Declarations.
• print(), println(), and readln(): input and output without System.in and System.out with Implicitly Declared Classes and Instance Main Methods.
• Use Flexible Constructor Bodies to initialize fields in constructors before calling super(...).

In addition, many other features introduced in Java 21 and Java 22 are entering a new preview round with or without minor changes.

String templates, introduced in Java 21 and reintroduced in Java 22, are an exception: They are no longer included in Java 23. According to Gavin Bierman, there is agreement that the design needs to be revised, but there is disagreement as to how this should actually be done. The language developers have, therefore, decided to take more time to revise the design and present the feature in a completely revised form in a later Java version.

As always, I use the original English titles for all JEPs and other changes.

Markdown Documentation Comments – JEP 467

To format JavaDoc comments, we have always had to use HTML. This was undoubtedly a good choice in 1995, but nowadays, Markdown is much more popular than HTML for writing documentation.

JDK Enhancement Proposal 467 allows us to write JavaDoc comments in Markdown from Java 23 onwards.

The following example shows the documentation of the Math.ceilMod(...) method in the conventional notation:

/**
 * Returns the ceiling modulus of the {@code long} and {@code int} arguments.
 * <p>
 * The ceiling modulus is {@code r = x – (ceilDiv(x, y) * y)},
 * has the opposite sign as the divisor {@code y} or is zero, and
 * is in the range of {@code -abs(y) < r < +abs(y)}.
 *
 * <p>
 * The relationship between {@code ceilDiv} and {@code ceilMod} is such that:
 * <ul>
 *   <li>{@code ceilDiv(x, y) * y + ceilMod(x, y) == x}</li>
 * </ul>
 * <p>
 * For examples, see {@link #ceilMod(int, int)}.
 *
 * @param x the dividend
 * @param y the divisor
 * @return the ceiling modulus {@code x – (ceilDiv(x, y) * y)}
 * @throws ArithmeticException if the divisor {@code y} is zero
 * @see #ceilDiv(long, int)
 * @since 18
 */Code language: Java (java)

The example contains formatted code, paragraph marks, a bulleted list, a link, and JavaDoc-specific information such as @param and @return.

To use Markdown, we need to start all lines of a JavaDoc comment with three slashes. The same comment in Markdown would look like this:

/// Returns the ceiling modulus of the `long` and `int` arguments.
///
/// The ceiling modulus is `r = x – (ceilDiv(x, y) * y)`,
/// has the opposite sign as the divisor `y` or is zero, and
/// is in the range of `-abs(y) < r < +abs(y)`.
///
/// The relationship between `ceilDiv` and `ceilMod` is such that:
///
/// – `ceilDiv(x, y) * y + ceilMod(x, y) == x`
///
/// For examples, see [#ceilMod(int, int)].
///
/// @param x the dividend
/// @param y the divisor
/// @return the ceiling modulus `x – (ceilDiv(x, y) * y)`
/// @throws ArithmeticException if the divisor `y` is zero
/// @see #ceilDiv(long, int)
/// @since 18Code language: Java (java)

This is both easier to write and easier to read.

What has changed in detail?

• Source code is marked with `...` instead of {@code ...}.
• The HTML paragraph character <p> has been replaced by a blank line.
• The enumeration items are introduced by hyphens.
• Instead of {@link ...}, links are marked with [...].
• The JavaDoc-specific details, such as @param and @return, remain unchanged.

The following text formatting is supported:

/// **This text is bold.**
/// *This text is italic.*
/// _This is also italic._
/// `This is source code.`
///
/// ```
/// This is a block of source codex.
/// ```
///
///     Indented text
///     is also rendered as a code block.
///
/// ~~~
/// This is also a block of source code
/// ~~~Code language: Java (java)

Enumerated lists and numbered lists are supported:

/// This is a bulleted list:
/// – One
/// – Two
/// – Three
///
/// This is a numbered list:
/// 1. One
/// 1. Two
/// 1. ThreeCode language: Java (java)

You can also display simple tables:

/// | Binary | Decimal |
/// |--------|---------|
/// |     00 |       0 |
/// |     01 |       1 |
/// |     10 |       2 |
/// |     11 |       3 |Code language: Java (java)

You can integrate links to other program elements as follows:

/// Links:
/// – ein Modul: [java.base/]
/// – ein Paket: [java.lang]
/// – eine Klasse: [Integer]
/// – ein Feld: [Integer#MAX_VALUE]
/// – eine Methode: [Integer#parseInt(String, int)]Code language: Java (java)

If the link text and link target are to be different, you can place the link text in square brackets in front:

/// Links:
/// – [ein Modul][java.base/]
/// – [ein Paket][java.lang]
/// – [eine Klasse][Integer]
/// – [ein Feld][Integer#MAX_VALUE]
/// – [eine Methode][Integer#parseInt(String)]Code language: Java (java)

Last but not least, JavaDoc tags, such as @param, @throws, etc., are not evaluated if used within code or code blocks.

New Preview Features in Java 23

Java 23 introduces two new preview features. You should not use these in production code, as they can still change (or, as in the case of string templates, can be removed again at short notice).

You must explicitly enable preview features in the javac command via the VM options --enable-preview --source 23. For the java command, --enable-preview is sufficient.

Module Import Declarations (Preview) – JEP 476

Since Java 1.0, all classes of the java.lang package are automatically imported into every .java file. That’s why we can use classes like Object, String, Integer, Exception, Thread, etc. without import statements.

We have also always been able to import complete packages. For example, importing java.util.* means that we do not have to import classes such as List, Set, Map, ArrayList, HashSet and HashMap individually.

JDK Enhancement Proposal 476 now allows us to import complete modules – more precisely, all classes in the packages exported by the module.

For example, we can import the complete java.base module as follows and use classes from this module (in the example List, Map, Collectors, Stream) without further imports:

import module java.base;

public static Map<Character, List<String>> groupByFirstLetter(String... values) {
  return Stream.of(values).collect(
      Collectors.groupingBy(s -> Character.toUpperCase(s.charAt(0))));
}Code language: Java (java)

To use import module, the importing class itself doesn’t need to be in a module.

Ambiguous Class Names

If there are two imported classes with the same name, such as Date in the following example, a compiler error occurs:

import module java.base;
import module java.sql;

. . .
Date date = new Date();  // Compiler error: "reference to Date is ambiguous"
. . .Code language: Java (java)

The solution is simple: we also have to import the desired Date class directly:

import module java.base;
import module java.sql;
import java.util.Date;  // ⟵ This resolves the ambiguity

. . .
Date date = new Date();
. . .Code language: Java (java)

Transitive Imports

If an imported module transitively imports another module, then we can also use all classes of the exported packages of the transitively imported module without explicit imports.

For example, the java.sql module imports the java.xml module transitively:

module java.sql {
  . . .
  requires transitive java.xml;
  . . .
}Code language: Java (java)

Therefore, in the following example, we do not need any explicit imports for SAXParserFactory and SAXParser or an explicit import of the java.xml module:

import module java.sql;

. . .
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();
. . .Code language: Java (java)

Automatic Module Import in JShell

JShell automatically imports ten frequently used packages. This JEP will make JShell import the complete java.base module in the future.

This can be demonstrated very nicely by calling up JShell once without and once with --enable-preview and then entering the /imports command:

$ jshell
|  Welcome to JShell -- Version 23-ea
|  For an introduction type: /help intro

jshell> /imports
|    import java.io.*
|    import java.math.*
|    import java.net.*
|    import java.nio.file.*
|    import java.util.*
|    import java.util.concurrent.*
|    import java.util.function.*
|    import java.util.prefs.*
|    import java.util.regex.*
|    import java.util.stream.*

jshell> /exit
|  Goodbye

$ jshell --enable-preview
|  Welcome to JShell -- Version 23-ea
|  For an introduction type: /help intro

jshell> /imports
|    import java.baseCode language: plaintext (plaintext)

When starting JShell without --enable-preview, you will see the ten imported packages; when starting it with --enable-preview, you will only see the import of the java.base module.

Automatic Module Import in Implicitly Declared Classes

Implicitly declared classes also automatically import the complete java.base module from Java 23 onwards.

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

With instanceof and switch, we can check whether an object is of a particular type, and if so, bind this object to a variable of this type, execute a specific program path, and use the new variable in this program path.

The following code block, for example, which has been permitted since Java 16, checks whether an object is a string of at least five characters and, if so, prints it in upper case. If the object is an integer, the number is squared and printed. Otherwise, the object is printed as it is.

if (obj instanceof String s && s.length() >= 5) {
  System.out.println(s.toUpperCase());
} else if (obj instanceof Integer i) {
  System.out.println(i * i);
} else {
  System.out.println(obj);
}Code language: Java (java)

Since Java 21, we can do the same much more clearly using switch:

switch (obj) {
  case String s when s.length() >= 5 -> System.out.println(s.toUpperCase());
  case Integer i                     -> System.out.println(i * i);
  case null, default                 -> System.out.println(obj);
}Code language: Java (java)

So far, however, this only works with objects. instanceof cannot be used with primitive data types at all, switch only to the extent that it can match variables of the primitive types byte, short, char, and int against constants, e.g., like this:

int x = ...
switch (x) {
  case 1, 2, 3 -> System.out.println("Low");
  case 4, 5, 6 -> System.out.println("Medium");
  case 7, 8, 9 -> System.out.println("High");
}Code language: Java (java)

JDK Enhancement Proposal 455 introduces two changes in Java 23:

• Firstly, all primitive types may now be used in switch expressions and statements, including long, float, double, and boolean.
• Secondly, we can also use all primitive types in pattern matching – both for instanceof and switch.