JDK 27: The quiet before the storm

Every September, with metronomic regularity, we have a new version of the Java platform. One small point about timing is that the first release candidate of JDK 27 was delayed by two weeks due to the release of the first Critical Security Patch Update (CPSU) for the JDK. The need for a CPSU is a direct implication of AI models, such as Anthropic’s Claude Mythos, becoming much better at identifying vulnerabilities and developing exploits. If you’re not already re-evaluating your patch strategy for the JDK, you definitely should be.

As usual, the new features in each release of Java are primarily driven by a set of JDK Enhancement Proposals (JEPs). In JDK 27, we have nine JEPs, and five of them are features that continue to be revised under the preview feature and incubator modules concept.

Let’s start with those, as the changes are intentionally minor.

Preview and incubator features in JDK 27

JEP 537 brings the vector API back for a record-breaking twelfth incubator. This is not because the API has significant issues; it is because it is a component of the larger Project Valhalla. The API authors don’t want to finalize it until Valhalla is delivered (more on Valhalla later). As such, there are no changes from the version in JDK 26.

Structured concurrency returns for a solid seventh preview under JEP 533. This is part of the larger OpenJDK Project Loom, a set of features to improve the scalability and reliability of multi-threaded applications. Only minor changes in this release, primarily in the Joiner interface.

Lazy constants (JEP 531) return for a third preview. The idea behind this feature is deferred initialization and JVM trust. Lazy constants are data-carrying objects but are treated as true constants by the JVM. This enables the same performance optimizations as declaring a field final. Compared to final fields, however, lazy constants offer greater flexibility for developers in when they are initialized. There are only three small changes to the API in this release.

One feature of particular interest to me is JEP 532: primitive types in patterns, instanceof, and switch. I’ve been delivering a “Java puzzlers” session at conferences and JUGs, which has led to some interesting discussion points on how to use this feature. JDK 26 tightened some of the rules around pattern dominance in switches, but it is delivered without change in JDK 27.

The last preview feature in JDK 27 is JEP 538, PEM (Privacy-Enhanced Mail) encodings of cryptographic objects, now in its third preview. This API encodes and decodes cryptographic keys, certificates, and certificate revocation lists between objects and the widely used PEM transport format. This includes a number of minor changes to the API. One that caught my attention was the change in the primary PEM class from a normal object to a record. The reasoning for this is the inclusion of new constructors that accept Base64-encoded content in byte arrays.

Final features in JDK 27

Let’s move on to the remaining features, all of which are final.

JEP 534 now turns compact object headers on by default. Although in JDK 25 compact object headers were made final, they required an explicit command-line flag to enable them at run time. As a fundamental change to the JVM, they have now proven stable enough to be the default configuration. The benefit they bring is improved performance through reduced heap usage (the JEP cites a 22% reduction in heap space and an 8% reduction in CPU utilization for the SPECjbb2015 benchmark).

Another interesting change is JEP 523, which makes the G1 garbage collector (GC) the default in all situations. Since JDK 9, G1 has been the default for server-side applications, but the serial collector remained the default in resource-constrained environments (those with a single CPU or less than 1792 MB of physical memory). More recent changes to G1 allow it to perform as well as the serial collector in all environments. I suspect that, based on this change, we will soon see the serial collector deprecated and removed from OpenJDK.

An impressive-sounding feature is JEP 527, post-quantum hybrid key exchange for TLS 1.3. Post-quantum cryptography (PQC) refers to encryption and digital signature algorithms designed to remain secure against future attacks by quantum computers. Current cryptographic standards like RSA and ECC (Elliptic Curve Cryptography) rely on mathematical problems, such as factoring large numbers, that take standard computers thousands of years to solve. Quantum computers running Shor’s algorithm can solve these problems in hours or minutes. Even though quantum computers capable of this are not readily available at the moment, cybercriminals are already harvesting encrypted data, assuming they will be able to decrypt it with quantum computers in the future. This JEP integrates quantum-resistant algorithms into Java’s standard web and network security layer (TLS 1.3).

Finally, we

Read the original article: