Somewhere on a bank's application server this week, a TLS handshake ran a little differently than it did last Friday. Nobody noticed. That is precisely the point.
Oracle shipped Java 27 into general availability on September 15, and buried inside nine feature updates is a change that has nothing to do with speed or syntax and everything to do with a threat that does not yet exist: a quantum computer capable of shredding the encryption the internet runs on. Java 27 adds post-quantum hybrid key exchange for TLS 1.3 through JEP 527, along with runtime, security and developer updates from Oracle. It is a small, almost invisible line in a changelog that reflects one of the more consequential bets in enterprise software: that the plumbing needs fixing now, for a leak that might not spring for another decade.
The stakes are not abstract. Security researchers call the underlying risk "harvest now, decrypt later" — a threat model in which attackers steal encrypted data today and store it until quantum computers can decrypt it in the future. Nation-state actors do not need a working quantum computer today. They only need patience and a hard drive. Also known as store now, decrypt later, HNDL creates immediate risk for sensitive data that must remain confidential for years or decades. For a bank's customer records or a defense contractor's design files, "years or decades" is not a hypothetical shelf life — it is the whole point of the data.
The math, made someone else's problem
JEP 527 folds a NIST-standardized post-quantum algorithm directly into the JDK's TLS stack. JEP 527 adds ML-KEM key encapsulation to TLS 1.3 without requiring external libraries or provider configuration, meaning for most teams this means one less dependency and one less reason to maintain a custom security provider. Developers do not have to opt in or bolt on a third-party crypto library. The implementation follows NIST FIPS 203, so if your organization is already tracking post-quantum readiness, JDK 27 covers the transport layer. Under the hood, that means the hybrid exchange — X25519MLKEM768 enabled by default — runs automatically the moment an application negotiates a TLS 1.3 connection on the new runtime.
Why bother now, when nobody has built a quantum computer that can actually break RSA or elliptic-curve cryptography? Because the math of migration is unforgiving. Cryptographers frame it as a race between three numbers: how long your data needs to stay secret, how long it takes to migrate your systems, and how long until a quantum computer arrives. Mosca formalized the migration urgency as data shelf-life plus migration time exceeding the time until Q-Day, because migration time can exceed a decade for complex infrastructures, making the urgency for migration immediate even if Q-Day lies a decade away. Large organizations do not swap out cryptography overnight; a 2025 study found realistic migration timelines running five to seven years for small enterprises, eight to twelve years for medium enterprises, and twelve to fifteen or more years for large enterprises. If you start when the quantum computer actually shows up, you have already lost.
Google, for its part, is not waiting to find out. The company has set a 2029 internal deadline for its own post-quantum cryptography migration, a signal that carries particular weight given that Google's own researchers are producing the resource estimates that define the threat. Oracle building the same defense into the world's most widely deployed enterprise language, by default, effectively drags millions of applications toward that same finish line whether their developers asked for it or not.
The rest of the release earns its keep too
Post-quantum crypto is the headline, but Java 27 is not a one-trick release. Oracle announced general availability of JDK 27, delivering nine JEPs including hybrid key exchange for TLS 1.3, a new PEM encoding API, relaxed primitive type restrictions in pattern matching, G1 as the default garbage collector everywhere, compact object headers as default, a lazy constants API, structured concurrency, an enhanced Vector API, and JFR redaction of sensitive command-line and environment data.
The garbage-collector change sounds mundane until you consider how many production systems it touches. With JDK 27, G1 becomes the default garbage collector in all environments, rather than just in server environments, with goals to ensure that the HotSpot JVM will always select G1 and that performance including throughput, latency, memory footprint, and startup time does not degrade significantly. Compact object headers, meanwhile, promise real memory savings for data-heavy workloads: standard application code gets a 10–20% heap reduction automatically after upgrading. And the Vector API incubator nods toward Java's ambitions in a market it did not originally build for — a Vector API incubator for faster analytics and AI inference sits alongside the security work, a tacit admission that enterprise Java now has to compete for AI infrastructure workloads too.
None of it comes with the fanfare of a long-term release. JDK 27 has a 6-month support window, and the next LTS is JDK 29, scheduled for September 2027 — meaning if your project only upgrades on LTS boundaries, JDK 29 is your next window. Most enterprises will not run this exact build in production for years. But the cryptography inside it will already have done its job by the time they do: quietly resetting the industry default, so that by the time anyone asks whether Q-Day is real, Java stopped waiting for an answer.
