Java 27: Compact Object Headers Cut Heap 22%, G1 Default Everywhere, Post-Quantum TLS

Java 27 Release Overview

Oracle released Java 27 on September 15 (US time) as a non-LTS feature release with nine JEPs — four finalized and five in preview or incubation. The four final JEPs share a common trait: they take effect by default without any code changes, delivering immediate performance, security, and observability improvements.

Compact Object Headers (JEP 534)

On 64-bit JVMs, each object header previously occupied 96 bits (12 bytes): a Mark Word for lock state, GC age, and hash code, plus a Class Word pointing to class metadata. Since Java heaps are dominated by small objects — a DTO holding a single int still paid 12 bytes of overhead for 4 bytes of data — JEP 534 merges both words into a single 64-bit (8-byte) word. The class pointer is compressed to 22 bits (1 KB block addressing, supporting ~4.2 million classes), and four spare bits are reserved for Project Valhalla.

Concrete gains from SPECjbb2015: heap usage drops 22%, CPU time falls 8%, and GC frequency decreases 15% . Applications with smaller objects benefit more. This feature evolved over years under Project Lilliput (initiated by Red Hat's Roman Kennke in 2021), entered experimentally in JDK 24, was finalized but opt-in in JDK 25, and becomes default only in JDK 27 . Amazon backported it to JDK 17/21 and validated it across hundreds of production services; SapMachine enabled it by default for customer workloads. Chinese enterprises including Alibaba and Ctrip have adopted it, though Ctrip encountered issues with native agents that depend on the old object-header layout. A fallback flag -XX:-UseCompactObjectHeaders restores the previous layout.

G1 as Universal Default Collector (JEP 523)

Since JDK 9, G1 has been the default on server-class machines, but the JVM quietly fell back to Serial GC on small-heap or single-core environments (e.g., 512 MB Kubernetes pods). JDK 27 removes that exception: when no collector is explicitly specified, G1 is used unconditionally . The confidence comes from JEP 522 in JDK 26, which drastically reduced G1's synchronization overhead, bringing throughput close to Serial.

Community caution: applications that previously "free-rode" on Serial GC in low-resource containers may see 5–15% response-time changes because G1's concurrent threads consume extra CPU. To revert, specify -XX:+UseSerialGC. The article recommends pre-upgrade testing in a staging environment, comparing four metrics — Young GC frequency, Full GC count, pause-time distribution, and heap size — and proceeding only if they show no regression.

Post-Quantum TLS 1.3 Hybrid Key Exchange (JEP 527)

This is arguably the most strategic JEP. Current RSA and ECDH key exchanges are theoretically vulnerable to quantum computers, and "harvest now, decrypt later" attacks are already underway — adversaries store ciphertext today for future decryption. JDK 27 adopts a hybrid approach: traditional ECDHE combined with the quantum-resistant ML-KEM algorithm, so the connection remains secure as long as at least one algorithm holds .

Three new named groups are added, aligned with IANA standards: X25519MLKEM768 (default preferred), SecP256r1MLKEM768, and SecP384r1MLKEM1024. Any application using javax.net.ssl benefits automatically with zero code changes. This caps a multi-release roadmap: JDK 21 introduced the KEM API (JEP 452), JDK 24 added the ML-KEM algorithm (JEP 496), and JDK 27 wires it into the TLS protocol layer. Oracle has committed to backporting equivalent capabilities to future LTS releases to minimize disruption. Fine-grained control is available via the system property -Djdk.tls.namedGroups=... or SSLParameters::setNamedGroups.

JFR In-Process Data Sanitization (JEP 536)

Java Flight Recorder recordings often capture command-line arguments, environment variables, and system properties that contain secrets such as API keys and database connection strings. JEP 536 ensures sensitive data is sanitized before it leaves the process , preserving diagnostic value while meeting compliance and privacy requirements — especially critical for AI systems that process sensitive data.

Long-Running Preview and Incubation Features

Structured Concurrency (JEP 533, 7th preview): Treats a group of related subtasks as a single unit of work; on scope exit, all subtasks are automatically cancelled and awaited, eliminating thread leaks. The community considers it near finalization, with high relevance for AI orchestration and parallel retrieval workloads.

Vector API (JEP 537, 12th incubation): The most persistent incubating feature. Official stance: it will advance to preview only after key Valhalla capabilities land. Targets AI inference and scientific computing.

Pattern Matching for Primitive Types (JEP 532, 5th preview): Allows switch and instanceof to work directly on int, long, and other primitives, simplifying code that mixes primitive and object data in AI and streaming pipelines.

Lazy Constants (JEP 531, 3rd preview) and Cryptographic Object PEM Encoding (JEP 538, 3rd preview) continue their preview cycles.

Project Valhalla Enters Mainline in JDK 28

The real "Easter egg" appears in the JDK 28 early-access builds: Project Valhalla Phase 1 lands as preview via JEP 401 (Value Classes and Objects) and JEP 539 . The integration pull request alone spans over 197,000 lines of code across 1,816 files ; other committers were asked to pause major changes during integration.

Immediate impact in preview mode: wrapper classes like Integer lose object identity, boxing overhead shrinks dramatically, and Integer[] performance approaches that of int[]. Code that synchronizes on boxed values — e.g., synchronized(Integer.valueOf(42)) — will throw exceptions. Language architect Brian Goetz dampened expectations, stating that even exiting preview by the next LTS (JDK 29) is "overly optimistic," and this is only the first part of Valhalla.

Ecosystem and Contributor Updates

Helidon 27: Version aligned with OpenJDK; built on virtual threads and Scoped Values; adds declarative gRPC/messaging modules and Helidon Data JDBC.

JavaFX 27: Switches to Metal rendering pipeline on macOS; enhances text editing controls and accessibility.

Oracle Jipher 20: Wraps a FIPS 140-3 validated OpenSSL module; adds ML-KEM/ML-DSA and KDF/HKDF support; included in the Java Verified Portfolio.

OCI: First cloud platform to support Oracle JDK 27.

The OpenJDK contributor list still features Alibaba, Amazon, ARM, Google, IBM, Microsoft, NVIDIA, Red Hat, and SAP, with independent developers contributing 16% of fixes.

Closing Perspective

Java 27 is not an LTS release; Oracle support ends March 2027, succeeded by JDK 28. The next LTS is JDK 29 in September 2027. The four final JEPs — smaller object headers, unified G1, quantum-resistant TLS, and self-sanitizing JFR — share a unifying theme: "do the right thing by default." No new syntax to learn, no frameworks to swap; upgrading itself delivers immediate value. More releases like this are welcome.