JDK 27 arrives September 15 – post-quantum crypto, smaller heaps and what’s coming in JDK 28

JDK 27 ships September 15, 2026. The release finalizes two years of incremental work on memory, concurrency and security and it brings one genuinely new capability: post-quantum cryptography in TLS 1.3, built into the JDK itself.

Post-quantum crypto in TLS 1.3

JEP 527 adds ML-KEM key encapsulation to TLS 1.3 without requiring external libraries or provider configuration. For most teams this means one less dependency and one less reason to maintain a custom security provider. The implementation follows NIST FIPS 203, so if your organization is already tracking post-quantum readiness, JDK 27 covers the transport layer.

G1 becomes the default everywhere

JEP 523 makes G1 the default garbage collector across all environments, including containerized deployments where CMS alternatives were sometimes still picked by default. For most applications nothing changes at runtime – G1 has been the practical default for years. Where it matters: teams with old JVM flags explicitly setting -XX:+UseG1GC can clean those up.

Smaller heap out of the box

JEP 534 enables compact object headers by default. In JDK 26 this was an opt-in experiment. Compact headers reduce object size from 16 bytes to 8 bytes for most objects, which cuts heap usage on typical workloads by 10–20%. Applications with millions of small objects: caches, message queues, graph structures will see this most.

Structured concurrency: seventh preview

JEP 533 delivers the seventh preview of Structured Concurrency. The API is stable enough to use in production with the understanding that it remains a preview feature. If you haven’t looked at it yet: StructuredTaskScope lets you fork multiple threads, then join them with defined cancellation semantics. If one subtask fails, the scope cancels the others automatically. It’s a cleaner replacement for manual ExecutorService management in request-scoped operations.

Pattern matching gets primitives

JEP 532 (fifth preview) extends pattern matching in instanceof and switch to primitive types. case int i when i > 100 now works without boxing. This closes a long-standing gap where developers had to work around primitives in otherwise clean pattern-matching code.

What’s worth watching in the release notes

PEM encoding APIs (JEP 538) hit their third preview. If your application reads or writes certificates and private keys, this API will eventually replace the awkward PEMParser / PEMWriter dance from BouncyCastle. Third preview means the API shape is close to final.

What’s coming in JDK 28 (March 2027)

Two features in JDK 28 will matter to most Java developers:

Simple JSON API (JEP 540). Standard JSON parsing and generation, no external library required. The API covers JsonValue, JsonObject, JsonArray, and basic serialization. It won’t replace Jackson for complex mapping, but it handles the case where teams pull in a 2 MB library to parse a config file or a webhook payload. Early access builds are available now.

Value Objects (JEP 401). Objects with only final fields and no object identity, no == comparison, no synchronization, no identity hash code. The JVM can inline them on the stack or in arrays without heap allocation. This is the Valhalla work finally landing. For library authors writing performance-sensitive data types, this changes the options.

JDK 28 also moves Shenandoah GC to generational mode by default and adds Strict Field Initialization (JEP 539), which prevents reading an uninitialized field a compile-time check that eliminates a class of NPE that current tools miss.

How to try it

JDK 27 early access builds are at jdk.java.net/27. SDKMAN users: sdk install java 27.ea-open and you’re running in under a minute. For JDK 28, early access is at jdk.java.net/28 – the Simple JSON API and Value Objects are already in the builds.