Java 27 Reaches General Availability, Finalizing Nine JEPs Including Default G1 GC and Post-Quantum TLS
Oracle's non-LTS Java 27 release makes G1 the universal default garbage collector, ships post-quantum TLS 1.3 key exchange, and finalizes compact object headers by default.
Overview
Oracle released Java 27 on September 15, 2026, according to OpenJDK’s official project page, finalizing a set of nine JEPs (JDK Enhancement Proposals) that make the G1 garbage collector the default in every environment and bring post-quantum key exchange to TLS 1.3. The release is the second non-LTS version following JDK 25, according to InfoQ, continuing Java’s twice-yearly feature-release cadence.
What We Know
The headline change is JEP 523, which makes G1 the default garbage collector across all environments rather than only server environments, as it has been since G1 first became the server default in JDK 9. Previously, constrained settings fell back to the Serial collector. According to the JEP text, “G1’s performance is now sufficient to replace Serial in all situations in which the JVM would previously have selected Serial,” with the JEP noting that “G1 is now competitive with Serial at all heap sizes” and that “G1’s maximum throughput is close to that of Serial.” InfoWorld confirmed the change: “G1 becomes the default garbage collector in all environments, rather than just in server environments.”
On the security side, JEP 527 introduces post-quantum hybrid key exchange for TLS 1.3, aiming to “enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms for TLS 1.3.” The JEP adds three hybrid schemes that pair the post-quantum ML-KEM algorithm with traditional elliptic-curve exchange — X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 — with X25519MLKEM768 prioritized by default in TLS handshakes. Applications using the standard javax.net.ssl APIs get the protection automatically, without code changes.
JEP 534 makes compact object headers the default header layout in HotSpot, shrinking object headers from 96 bits to 64 bits on 64-bit architectures. The JEP reports that the SPECjbb2015 benchmark showed “22% less heap space and 8% less CPU time” with the change, that garbage-collection frequency dropped 15% under both the G1 and Parallel collectors, and that a parallel JSON parser benchmark ran with “10% less time.” The feature builds on work first delivered as an opt-in flag in JDK 25 via JEP 519, as previously reported.
The remaining JEPs extend features already moving through Java’s multi-release preview process: Lazy Constants reaches a third preview (JEP 531), Primitive Types in Patterns, instanceof, and switch reaches a fifth preview (JEP 532), Structured Concurrency reaches a seventh preview (JEP 533), the Vector API reaches a twelfth incubator round (JEP 537), and PEM Encodings of Cryptographic Objects reaches a third preview (JEP 538). JEP 536 adds JFR In-Process Data Redaction, letting users redact command-line arguments and the initial values of environment variables and system properties in Java Flight Recorder recordings, according to InfoWorld.
Donald Smith, VP of Product Management in the Java Platform Group at Oracle, told SD Times that “we focus on putting innovation at the tip, so the latest versions of the JDK is where we focus on new, innovative, exciting things.” He added: “Where we’re deep in the internals of the platform, we’re adopting new hardware architectures, new trends in the industry, adding new features in that direction, but the tail is where the enterprises really benefit from using Java because we focus very much on conservatism, making sure that we’re not making breaking changes at the tip when we have innovative features and implementations that have proven themselves to be stable, performant, and secure.”
What We Don’t Know
Oracle’s release notes do not specify how many of the five still-preview or incubator JEPs — Lazy Constants, Primitive Types in Patterns, Structured Concurrency, the Vector API, and PEM Encodings — will finalize in the next feature release. As previously reported, Java’s twice-yearly cadence had JDK 27 expected for September 2026 as far back as JDK 26’s March ship date; a separate earlier report had pegged JDK 27’s general-availability date at September 14, one day before it actually shipped on September 15.
Analysis
As a non-LTS release, Java 27 is aimed at developers tracking Oracle’s six-month “tip” cadence rather than enterprises anchored to long-term-support versions such as JDK 25. Its two largest changes — universal G1 and post-quantum TLS — both extend features Oracle previewed or partially shipped in earlier releases into broader defaults, reflecting Smith’s description of the tip releases as where Oracle tests new capabilities before they mature into the conservative, stability-focused tail branch enterprises rely on.