Java 27 — smaller objects, changed defaults, post-quantum TLS
Java 27 is the smallest release in a while — only nine JEPs — but almost everything in it is a changed default rather than new syntax. Nothing to write, yet what runs in production changes, either on upgrade now or when Java 29 (the next LTS, a year out) lands.
Compact object headers are now the default
Shipped in Java 25 behind -XX:+UseCompactObjectHeaders, which most people never turned on. In 27 it is on by default. Every heap object's header drops from 12 bytes to 8. Four bytes sounds trivial until you remember the heap holds hundreds of millions of small objects — every Optional, DTO, and list element.
JEP 450's numbers on SpecJBB 2015: 22% less heap, 8% less CPU time, 15% fewer garbage collections. One benchmark, so don't expect your AWS bill to drop 22%. But Amazon already runs hundreds of production services with it backported to 17 and 21, and SAP made it the default in their JDK before Oracle did. If something breaks you can flip the flag off, though that is temporary — the plan is to delete the 12-byte headers from the JDK entirely.
G1 is now unconditionally the default collector
G1 has nominally been the default since Java 9, but only conditionally: if the JVM saw one CPU or under 1792 MB of memory, it silently gave you Serial instead. So small containers, Lambdas, and single-core pods have been on Serial all along, and the same app could run a different collector depending on the box it landed on. Java 27 removes the condition.
Not free: Oracle says on small boxes G1 uses about the same memory as Serial, with slightly lower throughput but better max latency. Better tail latencies for slightly worse raw throughput — usually the trade you want. Serial is still there via -XX:+UseSerialGC.
Flight Recorder redacts secrets
JFR records how the process was started, which historically meant access tokens in environment variables, keystore passwords in system properties, and database passwords on the command line all landed in the recording in plain text — and then into Jira tickets and AI agents. Java 27 redacts these in-process before anything is written to disk, by default.
Post-quantum key exchange in TLS 1.3 (JEP 527)
The one the video calls the fun one. The threat is "harvest now, decrypt later": someone captures your encrypted traffic today and holds it until a quantum computer can open it. Relevant for anything that still matters in a decade — medical records, bank transfers, government data.
JEP 527 adds a hybrid key exchange to TLS 1.3: it runs classical X25519 and post-quantum ML-KEM and combines both shared secrets. Hybrid because post-quantum algorithms have been broken before (SIKE), so the classical half is the fallback; an attacker would have to break both. If you use the standard javax.net.ssl stack and haven't overridden TLS named groups, you get it without code changes.
Still in preview / incubation
Lazy constants (3rd preview), primitive types in patterns (5th), PEM encoding (3rd), structured concurrency (7th, previewing since Java 21), and the Vector API (12th incubator, since Java 16). The Vector API is deliberately waiting on Valhalla so its API isn't finalized on an object model that value classes are about to change underneath it.
What's next
Java 28 in March brings Valhalla — value classes as a preview (JEP 401), after more than a decade of promises. Java 29 is the next LTS a year out, where most people will actually meet all of the above.