{"slug": "jdk-27-is-out-post-quantum-tls-and-g1-default-explained", "title": "JDK 27 Is Out: Post-Quantum TLS and G1 Default Explained", "summary": "JDK 27, released on September 15, 2026, by Oracle, now enables post-quantum TLS by default, reduces object header size by 25% (from 96 to 64 bits), and makes G1 the universal garbage collector, with SPECjbb2015 benchmarks showing 22% less heap usage and a 10% improvement in parallel JSON processing throughput. Developers must add X25519MLKEM768 to the jdk.tls.namedGroups property if they customize TLS groups, and can disable compact headers with -XX:-UseCompactObjectHeaders or restore Serial GC with -XX:+UseSerialGC.", "body_md": "JDK 27 went GA on September 15, 2026, and this is the kind of release that does meaningful work while you’re not paying attention. Post-quantum TLS is now on by default. Objects are smaller. G1 is the universal garbage collector. None of that requires a code change. Here is what actually changed — and the three things you need to check before you deploy.\n\n## Your TLS Is Now Quantum-Resistant\n\n[JEP 527](https://openjdk.org/jeps/527) adds post-quantum hybrid key exchange to TLS 1.3, enabled by default. The mechanism combines X25519 (classical elliptic-curve) with ML-KEM-768 (NIST FIPS 203, the quantum-resistant algorithm). When your Java application opens a TLS connection, it now simultaneously offers both a hybrid `X25519MLKEM768`\n\nkey share and a classical `x25519`\n\nshare. If the server supports the hybrid, it uses it. If not, it falls back gracefully. You get protection either way.\n\nThe threat this addresses is “harvest now, decrypt later” — adversaries recording your encrypted traffic today, betting they’ll be able to decrypt it once a capable quantum computer exists. Government, finance, and healthcare teams have been tracking [CISA’s 2030 post-quantum deadline](https://www.cisa.gov/quantum). Java 27 gets you there for transport security without writing a single line of new code, as long as you use the standard `javax.net.ssl`\n\nAPIs.\n\nThere is one catch: if your application explicitly configures TLS named groups via the `jdk.tls.namedGroups`\n\nsystem property, you need to add `X25519MLKEM768`\n\nto that list — or you will miss the hybrid schemes entirely. Check your JVM startup arguments before assuming you’re covered.\n\n## Objects Just Got 10–25% Smaller\n\n[JEP 534](https://openjdk.org/jeps/534) makes compact object headers the default. Every object on the JVM heap just shrank from 96 bits (12 bytes) to 64 bits (8 bytes). On a large heap, that compounds quickly. SPECjbb2015 benchmarks show 22% less heap usage and a 10% improvement in parallel JSON processing throughput. Amazon has been running this in production across hundreds of services — some on backports to JDK 17 and JDK 21 — and describing it as a free performance gain.\n\nThe feature has been through three JDK generations: experimental in JDK 24, a product feature in JDK 25, and now the default in JDK 27. If you held off in previous rounds, you no longer need to opt in. It is simply on.\n\nIf something breaks — unusual native-code behavior or unexpected serialization patterns — disable it with `-XX:-UseCompactObjectHeaders`\n\n. One flag to avoid: `-XX:+UseCompressedClassPointers`\n\nwas deprecated in JDK 25 and is now obsolete. Passing it in JDK 27 generates a warning and does nothing.\n\n## G1 Is Now the Default Everywhere\n\n[JEP 523](https://openjdk.org/jeps/523) removes the last environment where G1 was not the default. Previously, the JVM selected Serial GC on machines with fewer than two CPUs or less than 1.79 GB of RAM — a heuristic inherited from an era when G1’s overhead was a real concern. JDK 26’s JEP 522 closed the throughput gap, making the split behavior unnecessary.\n\nFor server applications and well-provisioned containers, nothing changes. For JavaFX desktop apps, small-container deployments, or embedded JVM use cases that never specified a GC flag, the JVM now uses G1. The practical result: lower maximum pause times, slightly lower raw throughput, and consistent GC behavior across all environments. SPECjbb2015 data shows 22% less heap, 8% less CPU, and 15% fewer GC events compared to the old defaults.\n\nTo preserve the old behavior: add `-XX:+UseSerialGC`\n\nto your JVM arguments. Serial GC remains available — it just no longer wins by default.\n\n## Structured Concurrency: Seven Previews In, Finalization Near\n\nJEP 533 delivers the seventh preview of structured concurrency with minor API refinements: a new `ExecutionException`\n\ntype for cleaner exception propagation and an updated `Joiner`\n\ninterface. If you’ve been using `StructuredTaskScope`\n\nin a prior preview, update your code to the new API shape — this version is likely the basis for finalization in JDK 28.\n\nSeven previews is a long runway. The community has expected finalization since JDK 25. At this point, building on it behind `--enable-preview`\n\nis a reasonable production bet for teams already on modern JDK versions.\n\n## What Else Landed in JDK 27\n\n**JFR Data Redaction (JEP 535):** Strips sensitive values — command-line arguments, environment variables, system properties — from JDK Flight Recorder recordings before they leave the JVM process. Closes a real secret-leakage path for teams shipping JFR data to external observability platforms.**PEM Encodings (JEP 538, third preview):** A native Java API for reading and writing TLS certificates and cryptographic keys in PEM format, replacing the BouncyCastle workarounds most teams use today.**Lazy Constants (JEP 531, third preview):** JVM-level constants with flexible initialization timing — the same JIT optimizations as`static final`\n\n, without the static initializer constraint.**Primitive Types in Patterns (JEP 532, fifth preview):** Pattern matching now works with all primitive types in`instanceof`\n\nand`switch`\n\nexpressions.\n\n## Should You Upgrade?\n\nJDK 27 is not an LTS release — the current LTS is JDK 21, with JDK 25 as the next. Enterprise teams locked to LTS have no forcing function here. But the security case for post-quantum TLS is real, and compact object headers are a free heap win that Amazon is already collecting at scale.\n\nIf you are on JDK 25 or JDK 26, upgrading is low-risk. The breaking changes are minor: `UseCompressedClassPointers`\n\nis obsolete, legacy ISO locale codes are removed, and `GZIPInputStream`\n\nreverts to its pre-JDK 23 behavior. Review the [official release notes](https://jdk.java.net/27/release-notes), run your test suite, and watch GC logs on first deployment to confirm G1 behavior is as expected.\n\nFor teams on JDK 21 LTS: the post-quantum TLS case alone is worth benchmarking a JDK 27 build in staging. If your threat model includes compliance with [post-quantum cryptography standards](https://www.infoq.com/news/2026/08/java-27-so-far/), you may want to move sooner than the next LTS cycle forces you to.", "url": "https://wpnews.pro/news/jdk-27-is-out-post-quantum-tls-and-g1-default-explained", "canonical_source": "https://byteiota.com/jdk-27-released-post-quantum-tls-g1-default/", "published_at": "2026-09-01 00:08:26+00:00", "updated_at": "2026-09-01 00:22:19.561078+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Oracle", "JDK 27", "JEP 527", "JEP 534", "JEP 523", "JEP 533", "G1", "ML-KEM-768"], "alternates": {"html": "https://wpnews.pro/news/jdk-27-is-out-post-quantum-tls-and-g1-default-explained", "markdown": "https://wpnews.pro/news/jdk-27-is-out-post-quantum-tls-and-g1-default-explained.md", "text": "https://wpnews.pro/news/jdk-27-is-out-post-quantum-tls-and-g1-default-explained.txt", "jsonld": "https://wpnews.pro/news/jdk-27-is-out-post-quantum-tls-and-g1-default-explained.jsonld"}}