By ByteBot
JDK 27 goes GA on September 15, 2026 — eleven days from now. Nine JEPs, which is light by recent standards. But three of them change runtime defaults, meaning your Java app’s behavior may shift the moment you upgrade your JVM without touching a single line of application code. If you run Java in containers, handle TLS connections, or care about heap efficiency, here is what you need to check before you pull that release tag.
Post-Quantum TLS Is Now On by Default
JEP 527 adds ML-KEM hybrid key exchange to TLS 1.3, and it requires zero configuration. Starting with JDK 27, a Java TLS client automatically offers both a quantum-resistant X25519MLKEM768 key share and the classical x25519 key share in the same handshake. If the server does not understand the hybrid offer, it ignores it and the connection falls back cleanly. Nothing breaks. Servers that do support ML-KEM hybrid get post-quantum protection automatically.
“Harvest now, decrypt later” is not a theoretical threat — state-level actors are actively collecting encrypted traffic today, expecting quantum computers capable of breaking ECDHE to arrive within the decade. NIST finalized ML-KEM in 2024. Finance, healthcare, and government contractors are already under pressure to adopt it. JDK 27 hands them compliance without a migration project. Go added post-quantum TLS hybrid in Go 1.23 with one scheme; Java 27 ships three and enables them by default.
There is one catch: if your code explicitly sets jdk.tls.namedGroups or calls SSLParameters::setNamedGroups, you have opted out of the default group ordering — and that means opting out of the hybrid groups too. You will need to add them back manually. Check your TLS configuration code before assuming post-quantum protection is active.
// Verify your TLS named groups after upgrading to JDK 27
SSLContext context = SSLContext.getInstance("TLS");
SSLParameters params = context.getDefaultSSLParameters();
System.out.println(Arrays.toString(params.getNamedGroups()));
// JDK 27 default output includes: X25519MLKEM768, x25519, secp256r1...G1 Is Now the Default GC for Small Containers Too
Before JDK 27, HotSpot had a sensible heuristic: single CPU or less than 1,792 MB of RAM meant Serial GC by default. Most Docker containers, Lambda functions, and Knative services fell into this bucket. Starting with JDK 27, G1 is the default in all environments, full stop.
This is not purely good news. G1 delivers lower maximum latency than Serial but uses more CPU cycles to do so. A throughput-first, single-CPU container service can see CPU usage climb or throughput dip when it silently switches to G1. The OpenJDK team has done substantial work to make G1 competitive with Serial in constrained settings, and the difference is small in most cases — but “most cases” is not “your case.” BestHub documented the exact scenario where a service slows down without a single code change.
The fix is straightforward: test your container-bound services under JDK 27 before shipping. If you want Serial behavior, add -XX:+UseSerialGC explicitly. The real mistake would be upgrading in production and assuming GC behavior is unchanged simply because you never set a GC flag before.
Compact Object Headers Are Now Free Performance
JDK 24 introduced compact object headers as experimental. JDK 25 made them opt-in with -XX:+UseCompactObjectHeaders. JDK 27 makes them the default — no flag, no action required.
Object headers shrink from 96–128 bits down to 64 bits on 64-bit JVMs. Amazon tested this against hundreds of production services and reported 22% heap reduction and 8% CPU time savings on SPECjbb2015. GC cycle counts dropped 15%. Ionut Balosin’s independent benchmarks corroborate those numbers. For workloads with large object graphs — microservices with substantial in-memory caches, data processing pipelines — the gains compound. Smaller heap means more objects fit in CPU cache, which means faster throughput and lower cloud bills.
The risk is narrow but real: code using JNI that makes explicit assumptions about HotSpot’s header layout can break. This affects a small fraction of applications, mostly those wrapping native libraries with bespoke JNI bindings. For everyone else, this is a free upgrade.
JFR Now Hides Your Secrets
JEP 536 adds in-process data redaction to Java Flight Recorder. Command-line arguments, environment variables, and system properties containing sensitive values — -Ddb.password=..., AWS_SECRET_ACCESS_KEY — are redacted before they hit the recording file. This is default-on. If you have compliance requirements around diagnostic dumps, JDK 27 tightens that surface without any configuration change on your part.
The Preview Pipeline: Watch Structured Concurrency
Four preview features return in JDK 27: Structured Concurrency (seventh preview), Lazy Constants (third preview), PEM Encodings (second preview), and Primitive Type Patterns (second preview). The Vector API is still incubating in its ninth round. Seven previews for Structured Concurrency is a deliberate pace — OpenJDK would rather iterate longer than ship a half-baked API into an LTS release where it is stuck for a decade. Most observers expect Structured Concurrency to finalize in JDK 28 (March 2027), landing in JDK 29 LTS as a finished feature. InfoQ’s JDK 27 roundup covers the full JEP list.
Should You Upgrade?
JDK 27 is a short-term release with six months of Oracle support. The next LTS is JDK 29, arriving September 2027. Production teams running JDK 25 LTS have no compelling reason to move unless they specifically want post-quantum TLS now or need to validate compact header behavior against their workloads ahead of the LTS cycle.
If you are still on JDK 21 LTS, do not treat JDK 27 as a shortcut. Plan a direct migration to JDK 25 or wait for JDK 29. JDK 27’s real value is as a staging test bed: run it in your non-production environment, confirm your app behaves correctly with the new GC defaults and compact headers enabled, and bank that confidence for the LTS upgrade. ADTmag’s pre-release breakdown is a good companion read for teams planning their upgrade path.
The September 15 release is worth tracking on OpenJDK’s JEP 527 page for the post-quantum details. Early-access builds are available now if you want a head start.
