JDK 27 Arrives, and the Features Left in Preview Say More

JDK 27 shipped on September 15, 2026, and the headline is not the release itself, it is what Oracle was willing to finalize versus what it left simmering for years. Four changes went final without controversy: a safer default garbage collector, quantum-resistant encryption, smaller memory footprints, and automatic redaction of secrets in diagnostic data. Meanwhile structured concurrency, an API that reshapes how Java developers write multithreaded code, is stuck in its seventh preview round since debuting in JDK 21, and the Vector API has been incubating since 2021 with no finish line in sight. That gap tells you more about how Oracle actually makes decisions than any single feature does.

Key takeaways

JDK 27 finalizes four JEPs: G1 as the default garbage collector everywhere, post-quantum hybrid key exchange in TLS 1.3, compact object headers by default, and automatic redaction of secrets in Flight Recorder data.
Structured concurrency is in its seventh preview since JDK 21 (2023); a follow-up proposal, JEP 543, targets finalizing it without further changes in JDK 28.
The Vector API has incubated for twelve straight releases since JDK 16 in 2021, and by its own plan cannot graduate until Project Valhalla's value types ship.
JDK 27 is not a Long-Term Support release. The current LTS is JDK 25 (September 2025); the next is JDK 29, planned for September 2027, so most production teams do not need to touch JDK 27 at all.

The Four Features Oracle Was Confident Enough to Finalize

Out of nine JEPs (JDK Enhancement Proposals) delivered in JDK 27, only four crossed the finish line into permanent, non-preview status, according to release coverage from InfoQ and other outlets tracking the OpenJDK project. The rest are still marked preview or incubator, meaning their APIs can still change before they are safe to depend on in production code.

JEP	Feature	Status in JDK 27
523	G1 as the default garbage collector everywhere	Final
527	Post-quantum hybrid key exchange in TLS 1.3	Final
534	Compact object headers by default	Final
536	Automatic redaction of secrets in Flight Recorder data	Final
533	Structured concurrency	7th preview
532	Primitive types in patterns, instanceof and switch	5th preview
531	Lazy constants	3rd preview
538	PEM encodings of cryptographic objects	3rd preview
537	Vector API	12th incubator

The four finalized changes share a trait: none of them require an application developer to rewrite a line of code. The Garbage-First collector (JEP 523) now activates by default in every environment, not just on server-class machines, according to an OpenJDK quality-discuss mailing list thread on the change. Post-quantum hybrid key exchange (JEP 527) slots into TLS 1.3 connections automatically. Compact object headers (JEP 534) shrink the per-object memory overhead inside the JVM. Flight Recorder's new redaction behavior (JEP 536) strips sensitive JVM arguments and environment variables from diagnostic captures by default. Every one of these is a change to the runtime underneath your code, not to the code you write.

Structured Concurrency's Seventh Preview Shows How Cautious Java Has Become

Structured concurrency is the feature most backend Java developers have actually been waiting on. It treats a group of related tasks running on different threads as a single unit of work, which is meant to cut down on thread leaks and the kind of half-cancelled operations that make concurrent bugs so hard to reproduce. Oracle first previewed it in JDK 21 in 2023. JDK 27 delivers JEP 533, its seventh preview round, and according to InfoQ's coverage this round mainly reworks exception handling: the API's Joiner interface picks up a third type parameter so callers can express exactly what exception type a failed join can throw.

A separate, unsuffixed JEP, numbered 543, has now reached Candidate status with a plan to finalize structured concurrency in JDK 28 "without further change," per Oracle's own JEP tracker. If that holds, the API will have spent four full years and seven preview cycles in developers' hands before Oracle commits to it permanently. That is not a bug in the process. It is the process working as designed: once an API is final, Oracle has to support it more or less forever, so every remaining rough edge gets sanded down before that door closes.

The Vector API Has Waited Twelve Rounds Because It Is Waiting on Something Bigger

If structured concurrency looks slow, the Vector API looks almost frozen. It first incubated as JEP 338 back in JDK 16 in 2021. JDK 27 carries JEP 537, its twelfth consecutive incubator round, a run tracked release by release in InfoQ's recurring "Java NN so far" roundups. Unlike a preview feature, an incubating one is not even part of the standard Java API yet, developers have to opt in explicitly, and it can be reshaped or dropped with far less ceremony.

The reason it has not graduated is structural rather than a matter of neglect: by its own stated plan, the Vector API cannot move from incubation to preview until Project Valhalla's value types land in the JVM, since the vector API's performance model depends on how those value types get represented in memory. Oracle is effectively holding a finished-looking feature hostage to a much deeper, still-unfinished change to how the JVM stores data. That is a very different kind of caution than the one behind structured concurrency, where the holdup is API polish rather than a dependency on unshipped infrastructure.

Close-up of a computer processor circuit board

Why Security Ships in Six Months and APIs Take Years

Put the two tracks side by side and a pattern emerges. Changes that are invisible to application code, default garbage collector behavior, cryptographic primitives inside TLS, memory layout inside the JVM, log redaction, move on Java's ordinary six-month release cadence because a rollback or a JVM flag can undo them if something breaks. Changes that application developers write code directly against, concurrency primitives, pattern matching syntax, vector math APIs, move at a pace measured in years and JEP revisions, because once Oracle finalizes a public API, backward compatibility means it is effectively permanent.

✦ Free Newsletter ✦

Never miss a story

Tools, tutorials and AI deep-dives - straight to your inbox, every week.

Post-quantum cryptography is the clearest case of urgency winning over caution: the threat of a future quantum computer breaking today's key exchanges is treated as pressing enough to finalize in one release, even though the practical risk is still years out. Compare that to structured concurrency, where the risk of shipping a slightly wrong API shape is that millions of lines of production code inherit an awkward interface forever. Given that asymmetry, moving fast on the reversible stuff and slow on the permanent stuff is a rational allocation of risk, not institutional slowness for its own sake. Anyone who has watched a language commit to a syntax feature it later regretted, as covered in our look at React Compiler 1.0's own long road to general availability, will recognize the trade-off.

The Counterargument: Caution Has a Cost Too

The strongest case against Java's approach is that developer patience is not infinite. Kotlin's coroutines have offered a production-ready structured concurrency model for years, and Go built lightweight concurrency into the language from day one. Every year that Java's version stays in preview is a year that teams evaluating a new service in 2026 can reasonably choose a language where the equivalent feature already has a stable API and years of production hardening behind it. A slow, careful process protects existing Java codebases at the expense of new ones that might never get written in Java at all.

Digital padlock icon over a circuit board background

That criticism is fair, but it understates what backward compatibility is actually worth to the installed base. Java runs a large share of existing enterprise backend systems, the kind our overview of what actually matters in web development in 2026 keeps returning to: unglamorous, long-lived systems that cannot tolerate an API that quietly changes shape under a minor version bump. For that audience, a four-year preview process that ends with an API Oracle will support for a decade is a better trade than shipping something faster and less certain, even if it costs Java some of the greenfield projects that go to Kotlin or Go instead.

Who Should Upgrade to JDK 27 Now, and Who Can Wait

JDK 27 is not a Long-Term Support release. The current LTS is JDK 25, which reached general availability in September 2025, and the next one, JDK 29, is not planned until September 2027, according to Oracle's Java SE support roadmap. Oracle will only support JDK 27 itself until roughly March 2027, when JDK 28 supersedes it. Anyone who has had to plan around a forced upgrade after a support cutoff, the way we covered in Windows 11 24H2's own support deadline, will recognize why that short window matters. That timeline should shape who bothers to move at all.

Lines of source code displayed on a monitor

Upgrade now if: you specifically want post-quantum TLS protection ahead of any future migration deadline, want G1 running by default without setting JVM flags, or need Flight Recorder's automatic secret redaction for a compliance requirement today.
Wait if: your team was planning to build production code against structured concurrency or the Vector API. Both are still preview or incubator features whose method signatures can still change, most recently structured concurrency's own exception-handling rework in this very release.
Skip entirely if: you are running JDK 21 or JDK 25 under a standard LTS support contract with no urgent need for a JDK 27-specific feature. Non-LTS releases like JDK 27 exist mainly for teams who want to track new features early or contribute feedback, not for production systems that value multi-year stability, similar to the tradeoffs we outline in our look at how PHP has evolved its own runtime in 2026.

The one group that should pay close attention regardless of upgrade plans is anyone doing cryptography migration planning. Post-quantum hybrid key exchange landing as a finalized TLS 1.3 feature in a mainstream JVM is a signal that the industry timeline for quantum-resistant infrastructure is moving from theoretical to operational, even on platforms that otherwise move cautiously.

The Takeaway

Do not read JDK 27 as "Java's big September release." Read it as Oracle telling you, feature by feature, exactly how confident it is in each piece of work: confident enough to lock in the reversible infrastructure changes, not yet confident enough to lock in the APIs developers will have to live with for a decade. If you write Java for a living, the practical move is to adopt the finalized defaults freely and keep treating structured concurrency and the Vector API as previews, because that is exactly what Oracle itself is still calling them.