The next JDK 27 release due in September includes 9 JEPs with new and enhanced features. Although this is a non-LTS release, JDK 27 is still interesting to check out, especially for team planning the upgrade to the next LTS version.
So, let’s look at what JDK 27 has in stock!
Table of Contents
New Features
JEP 523: Make G1 the Default Garbage Collector in All Environments
OpenJDK offers not one but seven garbage collectors. Each of them is tailored to a specific scenario, so developers can choose a collector based on the performance requirements for throughput, latency, footprint, and startup time. But before Java 27, there was a catch. If the app was allocated a single CPU or less than 1792 MB of physical memory, Serial GC was chosen automatically. This was done intentionally, because years ago, tests showed that Serial GC had advantages in throughput and footprint in such environments.
A lot has changed since then. G1 GC, the default garbage collector in the JVM, has been constantly improved. Its latency has always been better than that of Serial GC. And now, G1 GC can also compete with Serial GC at all heap sizes.
Therefore, JEP 523 makes G1 GC the default collector in all environments regardless of the number of processors and the available physical memory.
JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
JEP 527 makes Java’s TLS 1.3 connections more ready for the post-quantum world by adding hybrid key exchange algorithms. They combine today’s proven cryptography with newer quantum-resistant cryptography.
The idea is to protect data from “harvest now, decrypt later” attacks, where someone stores encrypted traffic today and tries to break it later with a quantum computer.
For most Java apps using javax.net.ssl, this should work by default, with no code changes unless the code already selects specific key exchange schemes.
JEP 534: Compact Object Headers by Default
Compact Object Headers have recently been integrated into OpenJDK as part of Project Lilliput. It is a feature that reduces the size of object headers in the HotSpot JVM to 64 bits on 64-bit architectures. This helps to reduce heap size, especially in applications that create lots of small objects, CPU time, and improve deployment density.
The goal of the feature is to get better memory efficiency without changing Java code or object behavior.
JEP 534 makes compact object headers the default in the HotSpot JVM.
JEP 536: JFR In-Process Data Redaction
JEP 536 adds a new feature to Java Flight Recorder — in-process data redaction.
This means that JFR can hide sensitive startup data, like command-line arguments, environment variables, and system properties, before the recording leaves the running JVM. And it does it by default, without any additional configuration.
This is a very useful and log-needed feature because JFR files are often shared with support teams or stored in bug reports, and nobody wants a password accidentally preserved in a performance recording!
If an application needs the old behavior, however, redaction can be configured or turned off with JFR options.
Improved Features
JEP 531: Lazy Constants (Third Preview)
Lazy constants are objects holding immutable data. Like final fields, they are treated as constants by the JVM and allow for the same optimizations. But unlike finals, they don’t have to be initialized at the moment of creation. It allows the application to initialize incrementally and so, start faster.
JEP 531 re-previews the feature with several significant changes:
- Remove the low-level methods isInitialized() and orElse() to keep the API simpler and harder to misuse.
- Add a new factory method Set.ofLazy(...). This means you can define a fixed set of possible elements, but compute whether each one is actually included only when it is checked.
This is a preview feature so you have to enable preview features to use it.
JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview)
Primitive Types in Patterns, instanceof, and switch make Java pattern matching work with primitive types like int, long, double, and boolean. That means instanceof and switch can now reason about primitive values more directly. For example, a switch can match an int value using type patterns and guards. It makes numeric checks cleaner and more expressive.
JEP 532 re-previews this feature without change. Enable preview features to use it.
JEP 533: Structured Concurrency (Seventh Preview)
Structured concurrency is a feature that aims to improve the experience of working with concurrency in Java. The idea is to treat several related tasks as one unit, so they start together, finish together, and fail in a more predictable way. This is especially useful when one request needs several things in parallel, like loading a user, orders, and recommendations at the same time.
JEP 533 re-previews the feature with several changes. The main change is in the exception handling. The built-in joiners now throw the familiar ExecutionException, the same kind of exception Java developers already know from Future.get().
This is a preview feature so you have to enable preview features to use it.
JEP 537: Vector API (Twelfth Incubator)
Vector API provides a way to write complex vector algorithms directly in Java code. Developers can use a programming model that will enable reliable and efficient vectorization. Manually written vector loops can express high-performance algorithms, which an auto-vectorizer may never optimize.
This feature will be useful in various areas, including machine learning, linear algebra, cryptography, finance, and code within the JDK.
The Vector API was first introduced in JDK 16. JEP 529 re-incubates the Vector API without significant changes.
The long-term goal of the Vector API is to take advantage of Project Valhalla's features. This project aims to improve the Java object model. So, Vector API will incubate until necessary features of Project Valhalla become available as preview features. After that, Vector API will be promoted from incubation to preview.
JEP 538: PEM Encodings of Cryptographic Objects (Third Preview)
PEM Encodings of Cryptographic Objects is a new standard Java API for reading and writing files in the Privacy-Enhanced Mail transport format. This format is often used for cryptographic keys, certificates, and certificate revocation lists.
JEP 538 re-previews this API with a few changes like the addition of classes and methods, renaming of classes and making a PEM class an ordinary class instead of a record.
As it is in preview, you need to enable preview features to try it.
Conclusion
Early-access builds of JDK 27 are available so you can experiment with them now or wait for the GA of your favorite distribution in September.
