Java 27 Ships With Post-Quantum TLS and Default G1 GC

OpenJDK shipped Java 27 today, and the two changes that will actually touch production systems are ones most developers won't have to lift a finger for. Every 64-bit JVM now runs with 64-bit object headers instead of 96 by default, and every outbound TLS 1.3 connection now negotiates a post-quantum key exchange automatically. Nobody has to opt in to either. That's the story: Java's stewards keep shipping infrastructure-level defaults that quietly change how the JVM behaves for millions of running services, on a twice-a-year clock nobody outside the ecosystem tracks.

Build 35 of JDK 27 served as both the final release candidate and the general-availability build, which is unusually clean for a release this dense: nine JEPs landed, including two defaults, three previews advancing toward finalization, and one incubator in its twelfth round. Oracle's GPL builds are live at jdk.java.net/27 now, with Adoptium, Amazon Corretto and Azul builds expected within days.

RelatedDeno 2.9 Ships Desktop Apps and Post-Quantum Crypto

What actually shipped in JDK 27?

Two of the nine changes are now the default behavior for every application that doesn't touch a JVM flag:

• JEP 523, G1 as the default collector everywhere. G1 already ran by default on most heap sizes since JDK 9; this closes the remaining gap so Serial GC no longer kicks in automatically on small-heap configurations.
• JEP 534, compact object headers on by default. Every Java object's header shrinks from 96 bits to 64 bits on 64-bit platforms, a change first previewed in JDK 24 under a flag. Nobody has to touch a launch script to get it in JDK 27.
• JEP 527, post-quantum hybrid key exchange for TLS 1.3. Any code using the standard javax.net.ssl APIs now negotiates a hybrid key exchange, pairing a quantum-resistant algorithm with a classical one, without a line of code changing.
• JEP 536, JFR in-process data redaction. Java Flight Recorder can now scrub sensitive command-line arguments, environment variables and system properties before a recording ever leaves the process.

The rest are further along a runway that's been under construction for years: lazy constants (JEP 531, third preview), primitive types in patterns and switch (JEP 532, fifth preview), structured concurrency (JEP 533, seventh preview), the Vector API (JEP 537, twelfth incubator round) and PEM encodings for keys and certificates (JEP 538, third preview). None of those are finished. All of them are stable enough that production code is already testing against them.

Why does a 32-bit header cut actually matter?

Object headers don't hold your data. They're JVM bookkeeping: a mark word for the object's hash code, GC state and lock status, plus a compressed pointer back to the class metadata. Every single object pays that tax, whether it's a tiny wrapper around one integer or a multi-field record. Shrink the tax by a third and the win compounds across a heap holding millions of small objects, which describes most Java services running today. Expect smaller heaps for the same workload, better cache locality because more live objects fit in the same cache line, and lower GC pause times since there's less header data to walk. None of that shows up as a new API. It shows up as a slightly smaller cloud bill and a slightly calmer garbage collector, the kind of change that's easy to miss in a changelog and easy to notice in a memory profiler.

Why ship post-quantum TLS now, when quantum computers can't break anything yet?

The threat this defends against isn't a quantum computer that exists today. It's "harvest now, decrypt later": an adversary records encrypted TLS traffic now and holds it until a sufficiently powerful quantum computer can break the classical key exchange protecting it. For data with a long shelf life, health records, financial history, government communications, that's already a live risk even though the decryption capability is years away. NIST finalized its post-quantum standards in 2024, and JEP 527 wires a hybrid exchange, pairing a quantum-resistant algorithm with a conventional one, straight into the default TLS 1.3 handshake for any code calling the standard javax.net.ssl APIs. If your service does nothing but run on JDK 27, its TLS connections get quantum-resistant by default. Browsers and other TLS stacks have been rolling out equivalent hybrid schemes since 2024; Java catching up on the JVM side closes a real gap for enterprise services that talk TLS through the standard library rather than a third-party crypto stack.

Who actually needs to upgrade to JDK 27, and who should sit this one out?

Java's release model has run on a strict six-month clock since JDK 10, but not every release carries the same weight. JDK 27 is a feature release, not a Long-Term Support release, and Oracle only backs it with patches until JDK 28 arrives in March 2027. That's a narrow window for anything that isn't already comfortable riding the six-month train.

For a team on JDK 25 running production traffic, JDK 27 isn't the upgrade to chase, JDK 29 is. Framework and library maintainers, and anyone who wants an early read on structured concurrency or the primitive-patterns preview before they lock in for JDK 29, are the actual audience here.

RelatedJellyfin 12.0 Is Out, and Upgrading Rewrites Your Database

1. 2025-09JDK 25 ships as LTS Current production baseline for most enterprise Java
2. 2026-03JDK 26 ships Non-LTS, compact object headers still opt-in
3. 2026-09-15JDK 27 ships Compact headers and post-quantum TLS become default
4. 2027-03JDK 28 planned JDK 27 support ends here
5. 2027-09JDK 29 planned as next LTS Oracle's new 2-year LTS cadence, after 25

What does the JEP backlog say about where Java is headed?

Look at what's stuck in preview rather than what shipped as default, and a pattern shows up: Java's core concurrency and pattern-matching story is being rebuilt in public, one six-month increment at a time. Structured concurrency has now sat in preview for seven consecutive releases, longer than any other JEP currently active, because the API keeps changing shape based on real usage reports before it locks in as a permanent contract nobody can walk back. Primitive types in switch and instanceof, on its fifth preview, is closing the last gap between how primitives and objects behave in pattern matching, a seam that's existed since generics arrived in Java 5. Neither is cosmetic. Both change how idiomatic Java code will look once they finalize, most likely in the JDK 29 LTS window.

Our take

The headline features here aren't the ones with JEP numbers most developers will ever type into a search bar. Compact object headers and post-quantum TLS are the kind of change that a platform ships when it's mature enough to spend engineering effort on defaults nobody asked for by name, because the aggregate benefit across every running JVM outweighs the cost of a slightly awkward six-month release cycle. That's a strength of Java's current governance, not a weakness: nobody had to lobby their ops team for a memory win or a crypto upgrade, it just arrived.

The real decision point isn't whether JDK 27 is good. It clearly is. It's whether your team's release discipline matches Java's. Shops that track every six-month release get compact headers and post-quantum TLS four months before everyone else, at the cost of a narrower support window and features that are still visibly in flux. Shops on the LTS track get the same defaults, fully baked, in JDK 29 next September. Neither answer is wrong. Picking one without knowing which train you're actually on is the mistake.

Original analysis by GenZTech. Source: OpenJDK.