Java 27 arrives in GA with G1 as default and compact object headers

JDK 27, the reference implementation of Java 27, reached general availability (GA) on September 15, 2026, announced by Mark Reinhold on the official OpenJDK mailing list. The GA release shipped from build 35, the second Release Candidate published on August 20, with no P1 bugs reported since then. Oracle's GPL binaries are already available at jdk.java.net/27, and builds from other vendors (Temurin, Corretto, Zulu, Liberica) tend to follow shortly.

There are nine JEPs in total, listed on the JDK 27 project page. But the reading that matters for those operating JVMs in production isn't the count: it's that two of these changes alter defaults, meaning they apply even if you don't change a single line of code. And that's where the risk and the gain lie.

What changes without you asking: default G1 and compact headers

JEP 523 makes G1 the default garbage collector across all environments. In practice, G1 had already been the default in most scenarios for years; the change closes the edge cases where the JVM still automatically picked a different collector (for example, on small machines, with little memory or few cores, where the Serial GC could kick in). If you run lean containers, cheap VMs, or functions with tight CPU and memory limits (a common scenario for those optimizing cloud costs in Brazil), it's worth checking whether your service's GC behavior changes when you move to 27. Those who already pinned the collector explicitly with -XX:+UseG1GC won't notice any difference.

The most interesting cost/benefit change is JEP 534: Compact Object Headers by Default. Every object on the JVM heap carries a metadata header; historically that was 12 or 16 bytes per object. Compact headers reduce that, and the gain shows up directly in memory consumption and, consequently, in GC pressure. The feature already existed as experimental in earlier versions and now comes enabled by default. For applications with many small objects (the bread and butter of much of enterprise Java), this can mean less occupied heap and fewer collections, without touching a line of code.

The operational detail: since it's a new default, it's exactly the kind of thing that deserves a load test before going to production. Less memory per object is good, but a change in object layout and GC behavior needs to pass through your real environment, with your traffic profile, before you trust it blindly.

Post-quantum cryptography enters TLS

JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 is the Java platform's first concrete step toward quantum-resistant cryptography. The idea behind the hybrid scheme is to combine a classical algorithm with a post-quantum one in the TLS 1.3 key exchange, so the connection remains secure even if one of the two is broken in the future.

Why does this matter now, if a quantum computer capable of breaking current cryptography doesn't exist yet? Because of the "harvest now, decrypt later" threat model: traffic captured today can be stored and decrypted years later. For those handling long-lived sensitive data, healthcare, financial, data under LGPD (Brazil's data protection law) that needs to stay confidential for years, having hybrid key exchange support built into the JVM itself is a meaningful milestone. It's not something most people will flip on tomorrow, but it's the infrastructure arriving at the platform.

Preview and incubation: what's not for production yet

Much of the nine JEPs remain in preview or incubation phase, meaning they're in the JVM for experimentation and feedback, but require flags to enable and can change between versions. It's worth mapping them out because they point to where Java is headed:

• JEP 533: Structured Concurrency (seventh preview) continues maturing the model that treats groups of concurrent tasks as a single unit, aligned with the work on virtual threads. It's the piece that promises to make concurrent code more readable and less prone to thread leaks.
• JEP 532: Primitive Types in Patterns, instanceof, and switch (fifth preview) extends pattern matching to primitive types, one more step in the evolution of the language's switch and pattern matching.
• JEP 531: Lazy Constants (third preview) offers a standardized way to lazily initialize constants, useful for those who want to defer expensive computation without resorting to double-checked locking hacks.
• JEP 537: Vector API (twelfth incubator) keeps incubating, a sign that it's still waiting on Project Valhalla to stabilize. It matters to those doing heavy numerical computation who want explicit SIMD.
• JEP 538: PEM Encodings of Cryptographic Objects (third preview) and JEP 536: JFR In-Process Data Redaction round out the list, the first making it easier to work with keys and certificates in PEM format, the second allowing sensitive data to be redacted within Java Flight Recorder recordings, something directly useful for those who need observability without leaking PII in dumps.

Beyond the JEPs, the release brings, as always, hundreds of minor improvements and thousands of bug fixes.

Is it worth migrating now? Depends on LTS

The point the announcement doesn't answer, and the one that decides the fate of those operating JVMs in Brazil, is: Java 27 is not an LTS (Long-Term Support) release. The versions most companies pin in production are the LTS ones, with years of security updates. Between one LTS and the next, feature releases ship every six months and get short support.

In practice, this splits two audiences. If you keep your stack on LTS (11, 17, 21), Java 27 is the place to test Compact Object Headers, evaluate the impact of G1 as default on your load profile, and experiment with structured concurrency, all in a staging environment, so you arrive prepared for the next LTS. Those running services with a fast update cycle and mature testing infrastructure can reap the memory gains now.

The usual recommendation applies more than ever here: bring 27 up in staging, run your real load test paying attention to the default changes (GC and object headers), and only then decide. The two changes that stand on their own, default G1 and Compact Object Headers, are exactly the ones that need validation against your traffic before any promise of savings.