Java 27: What’s new? | Loic's Blog

Loic's Blog

Blog about IT developement, and some more stuff (travel, ecology, …)

Now that Java 27 is features complete (Rampdown Phase One at the day of writing), it’s time to walk through all the functionalities that bring to us, developers, this new version.

This article is part of a series on what’s new on the last versions of Java, for those who wants to read the others, here are the links: Java 26, Java 25, Java 24, Java 23, Java 22, Java 21, Java 20, Java 19, Java 18, Java 17, Java 16, Java 15, Java 14, Java 13, Java 12, Java 11, Java 10, and Java 9.

After Java 26 and its 10 JEPs, Java 27 arrives with a small number of JEPs, 9, with very few new features.

JEP 523: Make G1 the Default Garbage Collector in All Environments

G1 was set as the default Garbage Collector in Java 9. At that time, tests showed that for environments with one CPU (or fewer) and less than 1792 MB of heap, the Serial Garbage Collector was more efficient. The JVM therefore used Serial by default in these cases.

Since then, G1 has been improved, and tests have shown that G1 is now equivalent to Serial for all heap sizes. With improvements to reduce synchronization (JEP 522), G1 now performs as well as Serial , even with a reduced number of CPUs. Finally, G1 has also seen a reduction in its native memory consumption, reaching levels comparable to those of Serial .

Logically, since G1 is equal to or better than Serial on all criteria, even in environments with few CPUs and/or little RAM, it is now the default in all environments.

More information in JEP 523.

JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

Strengthens the security of Java applications requiring secure network communications by implementing hybrid key exchange algorithms for TLS 1.3. These algorithms help protect against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional one.

A hybrid key exchange algorithm combines a quantum-resistant algorithm with a traditional one and remains secure as long as one of the two algorithms is not broken. This approach helps protect against quantum attacks while acknowledging that these new algorithms have not yet benefited from the years of testing and analysis already conducted on traditional algorithms.

The JDK’s implementation of TLS 1.3 will support three new post-quantum hybrid key exchange schemes that combine the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM – added via JEP 496) with traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithms:

X25519MLKEM768 : hybrid scheme combining ECDHE with X25519 and ML-KEM-768,

SecP256r1MLKEM768 : hybrid scheme combining ECDHE using the secp256r1 curve with ML-KEM-768,

SecP384r1MLKEM1024 : hybrid scheme combining ECDHE using the secp384r1 curve with ML-KEM-1024.

More information in JEP 527.

JEP 534: Compact Object Headers by Default

Compact object headers allows the JVM to store object headers in 64 bits instead of 128: 22 bits for the class pointer, 31 bits for the hash code, 4 bits reserved for Valhalla, and the remaining bits as before for GC age and JVM flags.

Compact object headers were introduced as an alternative object header structure in preview in Java 24 via JEP 450, and then exited preview in Java 25.

Since then, compact object headers have proven their stability and performance.

They have been tested at Oracle using the JDK’s full test suite. They have also been tested at Amazon and SAP, which have enabled them by default.

Various experiments show that enabling compact object headers improves performance:

The SPECjbb2015 benchmark uses 22% less heap space and 8% less CPU time.

The number of garbage collections performed by SPECjbb2015 is reduced by 15%, both with the G1 collector and the parallel collector.

A highly parallel JSON parser benchmark runs 10% faster.

In Java 27, compact object headers are enabled by default. The old layout is expected to be deprecated in a future release.

More information in JEP 534.

JEP 536: JFR In-Process Data Redaction

JFR recording files contain command-line arguments as well as environment variable values and system properties, which show how the process was launched and configured. These events can therefore contain sensitive data, such as secrets in command-line arguments, environment variables, and system properties. Currently, this data appears as-is in the recording files, which poses a risk of sensitive information leakage when recordings are shared.

JFR will now mask many types of sensitive information by default, without any additional configuration.

You can explicitly select the information that JFR should mask using new sub-options of the existing command-line option -XX:FlightRecorderOptions. Each sub-option specifies one or more filters that select the command-line arguments, environment variables, and system properties to mask.

The redact-argument sub-option specifies a list of filters for...