Java 27 grows up, makes better choices

devops

Improvements in JDK garbage collection, header sizes, data security and quantum key support all should minimize developer friction

If one sign of maturity is making better choices, then Java has grown up a fair bit in its version 27 release Tuesday. 

“JDK 27 is the release where Java stops asking you to opt in to good defaults and simply turns them on,” wrote backend engineer Arvind Kumar, on his education site Codefarm. 

Better default settings may not be groundbreaking, but they do make life easier for developers because they mean coders have fewer things to change. Nor should users have to grapple with new features, particularly if they are not of interest. 

Java 27 succeeds on both counts.

Built from the now-completed Java 27 specification, JDK 27 is a short‑term release that won't get long-term support. It includes four new features, or JEPs (JDK Enhancement Proposals) that are ready for production, none of which, Kumar points out, require any immediate changes in developers' code. 

The release includes another five new features offered as previews for further incubation.  

Headers get compact

In Java 27, compact headers are now available by default (JEP 534). Up until now, the developer had to set them with a flag. Now, no additional action is required. 

Traditionally, a Java object header takes up 96 bits in a memory heap, much of which is rarely used. 

With Java 27, the default is a 64-bit header. Turns out the header had too much empty space. 

Four bytes doesn’t sound like a change to worry over, but across millions of live objects it can lead to considerable memory savings. A run on the SPECjbb2015 Java benchmark standard found that toggling to a 64-bit header resulted in 22% less heap space and 8% less CPU time.

The smaller headers appear to work in production. Amazon already runs hundreds of production services with the diminutive compact object headers. SAP has already switched to compact object headers as the default for the company’s OpenJDK fork, SapMachine.

Even in its smaller size, this new layout reserves some space for future projects, such as 4 bits for Project Valhalla which aims to bring value objects to Java. 

Java's overseers don’t want to toss the 96-bit header layout, at least for the time being. But now developers must raise a flag if they want to use it. 

Quantum-proofing cryptography

Looking ahead to the arrival of quantum computing, Java maintainers have implemented “post-quantum hybrid key exchange,” based on TLS 1.3 (JEP 527).

Java now offers three new “hybrid” ways of exchanging keys between Java clients, servers and external TLS-compliant endpoints. Each of these approaches, which are options alongside the existing key exchange protocols, combines a traditional Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE) algorithm with the NIST ML-KEM post‑quantum key exchange algorithm. 

The idea is to prepare now for future quantum attacks when the keys to traditional key exchanges could be easily cracked with quantum computing. Malicious attackers are already saving encrypted sessions with a "harvest now, decrypt later" mindset.

Taking out the trash, in a good way

JDK 27 also tidies up its garbage collectors, the tools that quietly identify and reclaim unused memory. It switched out the default trash bin for constrained environments – Serial – to the overall default garbage collector, called Garbage-First or G1. Garbage collectors relieve developers from manually performing this task and potentially messing it up (usually).

But it comes with a cost. Aggressive memory management adds overhead. So different garbage collectors have been built to meet different performance requirements regarding throughput, latency, footprint, and startup time.

Recent performance improvements in G1 effectively rendered Serial GC unnecessary, Java's bosses argue. Serial was a single-threaded app built to run on a single CPU, making it well-suited to embedded and other resource-limited environs (especially with clients with less than 1792MB of memory). 

Thanks to optimization over the years, “G1's performance is now sufficient to replace Serial in all situations in which the JVM would previously have selected Serial,” the maintainers write in JEP 523. 

With this change, embedded developers will no longer have to add explicit flags to the command line during startup. Even better, it will correct cases where G1 should have been assigned in the first place, such as for containerized apps. 

“A chunk of containerized Java apps has been running on [Serial] all this time, even though no one consciously made that decision,” wrote PVS-Studio technical author Egor Pishii in a post. 

The switchover will also help unify telemetry data collection a bit more.

Preparing Java 28

The remaining production-ready feature is in-process data redaction (JEP 536), in which Java’s Flight Recorder removes all sensitive details before the recording is finalized.  

The previews that come with this release include lazy constants (JEP 531), pattern primitive types (JEP 532), structured concurrency (JEP 533), and a set of cryptographic objects (JEP 538). There’s also a vector API (JEP 537) still in the incubation stage.  We’ll see all of these again, hopefully in a more polished form, in a later release.

Work is already underway for Java 28, due in March 2027: Expect a simple JSON API as an incubating project as well as a revised Shenandoah garbage collector. ®