Java 27 Is Out: Post-Quantum TLS and Compact Headers

Java 27 shipped today. It’s not an LTS release — Java 25 holds that designation through September 2030 — and most production teams will reasonably stay put. But “I’m not upgrading” and “nothing changed” are not the same thing. Three features in JDK 27 land at the JVM level, affect existing codebases, and deserve attention regardless of whether you touch your deployment. The rest are previews still finding their shape. Here’s what actually matters.

Compact Object Headers Cut Heap by 22% (JEP 534)

Every Java object carries a header: metadata the JVM uses for identity, locking, and garbage collection. For decades, that header consumed 96 bits (12 bytes) on 64-bit JVMs. Java 27 shrinks it to 64 bits (8 bytes) by merging the Mark Word and Class Word into a single 64-bit structure.

That sounds like a compiler footnote. The impact is not. Benchmark data from Amazon production testing shows the SPECjbb2015 workload using 22% less heap, 8% less CPU time, and producing 15% fewer GC cycles. A highly parallel JSON parser ran 10% faster. At 10 million live objects — common in any reasonably sized service — that is 80 MB of header overhead gone.

It is enabled by default. No JVM flags, no code changes, no migration checklist. If you are staying on Java 25 LTS, you can backport the flag: -XX:+UseCompactObjectHeaders was production-ready since Java 25. The benefit scales with how many small, short-lived objects your application creates — microservices doing high-throughput JSON processing stand to gain the most. The four reserved bits in the new header structure are explicitly set aside for Project Valhalla, which signals OpenJDK is thinking multiple releases ahead.

Post-Quantum TLS Is Now the Default (JEP 527)

There is a category of attack called “harvest now, decrypt later.” Adversaries intercept and store encrypted TLS traffic today, then wait for quantum computers capable of breaking the underlying key exchange to become viable. The data is useless now — it won’t be forever. Anything with a long sensitivity window — medical records, financial transactions, government communications — is a target.

Java 27 addresses this with hybrid key exchange for TLS 1.3. It pairs ML-KEM (the NIST-standardized quantum-resistant algorithm, formerly CRYSTALS-Kyber) with classical ECDHE. A hybrid scheme is secure as long as either algorithm holds. The OpenJDK specification frames it plainly: “secure as long as one of the algorithms remains unbroken” — a reasonable hedge against genuine uncertainty about the quantum timeline.

The default scheme is X25519MLKEM768, which activates automatically when the remote server supports it. Code using javax.net.ssl APIs gets the upgrade with zero changes. To customize the preference order, set the jdk.tls.namedGroups system property or call SSLParameters.setNamedGroups() programmatically. For the vast majority of applications: nothing to do.

G1 Is Now the Default GC on Every Machine (JEP 523)

This one has been a source of subtle production incidents for years. When a JVM ran on a single-CPU host or a machine with less than 1,792 MB of RAM, it defaulted to the Serial garbage collector. Developers running on fat local machines got G1. Their Kubernetes sidecar containers, Lambda functions, and edge deployments got Serial GC. The result: completely different garbage collection behavior between development and production, with performance cliffs that appeared under load but not in local testing.

JEP 523 ends that divergence. G1 is now the default on all machines without exception, made feasible by G1 throughput improvements over the past two releases that closed the gap with Serial GC’s core strength. Serial GC has not been removed — -XX:+UseSerialGC still works — but you would need a specific reason to reach for it.

Note that G1’s default heap free ratios also changed: MinHeapFreeRatio moves from 40% to 0%, and MaxHeapFreeRatio from 70% to 100%. The JVM will hold onto more heap rather than aggressively releasing it between GC cycles. Peak memory usage can look higher; GC pause frequency should look lower. Monitor both after any migration.

The Other Additions Worth Noting

JFR (Java Flight Recorder) now auto-redacts sensitive data from recordings by default. Environment variable names matching patterns like *password*, *token*, and *api*key* get masked before data leaves the process. This matters for teams sharing profiling artifacts or running JFR in CI pipelines where recordings can end up in build logs. Configure it via -XX:FlightRecorderOptions.

On the preview front: Structured Concurrency hits its seventh iteration with a breaking API change — FailedException becomes ExecutionException, and the joiner API gained a third type parameter for the exception type. If you have been tracking this API across previews, update your catch blocks. Primitive types in patterns (fifth preview) continues maturing, enabling switch on raw int values without boxing overhead. The Vector API sits at its twelfth incubation round without changes, still waiting on Project Valhalla value classes expected in Java 28.

// Primitive pattern matching preview (JEP 532)
switch (score) {
  case int s when s >= 90 -> System.out.println("excellent");
  case int s when s >= 75 -> System.out.println("good");
  default -> System.out.println("needs work");
}

Should You Upgrade?

In production: probably not. Java 25 LTS is the right production target through at least 2028, when Java 29 LTS is expected. Java 27’s official support window closes around March 2027 — too short for most enterprises to justify the migration cycle.

In CI and staging: yes, now. Run your test suite against JDK 27 builds, measure heap utilization and GC metrics, and start tracking how Structured Concurrency’s API is evolving. Java 28 (March 2027) is when Project Valhalla value classes arrive as a preview — the feature that will finally unblock the Vector API and reshape Java’s memory model. The upgrade path from Java 25 to Java 29 LTS will be smoother if you have been running Java 27 in your pipeline throughout 2026.

Java 27 is the platform doing its maintenance work — fixing the G1 default inconsistency, hedging against quantum threats, compressing headers, and tightening security defaults. None of it requires action. Most of it improves your application without asking permission. That is the kind of release that does not generate hype but compounds quietly over time.

---

Further reading: JEP 534: Compact Object Headers by Default | JEP 527: Post-Quantum Hybrid TLS | All nine JEPs via InfoWorld