Java Structured Concurrency finally finalized in JDK 28 after seven preview rounds

StructuredTaskScope API reaches final status with no changes from JDK 27 preview

By LineZotpaper

Published20 October 2026

Read Time2 min

JEP 543, Structured Concurrency, has been integrated into JDK 28, finalizing the StructuredTaskScope API after the longest preview cycle of any Project Loom feature. The API is now stable and usable without preview flags, requiring only a recompilation for teams already on JDK 27.

The finalized Structured Concurrency API, delivered through JEP 543, brings the StructuredTaskScope in java.util.concurrent to final status with no API changes from JDK 27's seventh preview. For codebases already on JDK 27, the migration comes down to recompiling without --enable-preview.

Structured concurrency debuted as an incubator API in JEP 428 (JDK 19) and JEP 437 (JDK 20), then progressed through seven previews from JDK 21 to JDK 27. Across every iteration, the core objective has been to treat groups of related subtasks running in different threads as a single unit of work, ensuring that a failure in one subtask cancels the others and that the parent scope cannot exit before all child threads have terminated. Traditional ExecutorService and Future pipelines do not enforce those boundaries.

The API centers on StructuredTaskScope, a sealed interface opened through static factory methods. The open() factory returns a scope where join() waits for all subtasks to succeed, cancels the rest on the first failure, and throws ExecutionException. Each fork() call starts a virtual thread by default. Completion policies are defined through the Joiner interface, offering policies such as allSuccessfulOrThrow, anySuccessfulOrThrow, and allUntil. Custom policies allow developers to surface application-specific checked exceptions directly from join().

The API is strict about structure: only the thread that opened the scope can call fork() and join(), results are read through Subtask.get() only after join() returns, and structural misuse fails fast with StructureViolationException. Subtasks inherit ScopedValue bindings from JEP 506 and appear under their parent in JSON thread dumps.

Teams coming from JDK 26 face more changes, including the replacement of FailedException with ExecutionException and removal of StructuredTaskScope.TimeoutException. The onTimeout() callback has been replaced by an abstract timeout() method.

The finalization commit only removes preview annotations and changes no method signatures. JDK 28 is scheduled for general availability in March 2027. The velo/structured-concurrency project already backports the JEP 543 API to JDK 25 and provides migration recipes.

Analysis

Why This Matters

Java developers building concurrent applications with virtual threads now have a stable, standardised API for managing groups of subtasks, eliminating the need for preview flags in production.
Library and framework maintainers can rely on structured concurrency without forcing preview flags on their users, enabling broader adoption in ecosystems like Spring, Quarkus, and Helidon.
The conclusion of the longest preview cycle in Project Loom signals that the core Loom feature set (virtual threads, structured concurrency, scoped values) is nearing full maturity.

Background

Project Loom has introduced virtual threads and related concurrency features into Java over several JDK releases. Structured concurrency was proposed to address the problem of subtask lifecycle management: without it, a parent method can exit while child threads continue running, and failures are only discovered when Future.get() is called. The API enforces a structured approach where the scope of subtasks is tied to a lexical block, ensuring proper cancellation and thread termination. From JDK 19 onward, the API evolved through incubator and preview stages, with each iteration refining the joining policies and exception handling based on community feedback.

Key Perspectives

Java developers on JDK 27: Migration is minimal — recompile without --enable-preview. No code changes are needed, as the API shape is identical. Library and framework maintainers: This finalization allows them to integrate structured concurrency into their APIs without requiring users to enable preview features, reducing friction for adoption. Oracle and the Java team: The seven-preview cycle and careful design reflect a commitment to getting the API right before finalising. The decision to leave the specific failure-join behaviour loosely specified (the Javadoc only promises the exception comes from a failed subtask) shows pragmatism in the face of edge cases.

What to Watch

Adoption rate of JDK 28 by major Java frameworks and application servers once it ships in March 2027.
Updates to the backport project velo/structured-concurrency, which already supports JDK 25 and may become a bridge for teams that cannot upgrade immediately.
Potential follow-up JEPs to formalise additional completion policies or integrate structured concurrency more deeply with the reactive streams ecosystem.

Sources

JEP 543 Finalizes Structured Concurrency in JDK 28, Ending Seven Preview Rounds · InfoQ

Checked

12 claims in this story checked against 1 source: 12 supported.

Show each claim

SupportedJava Structured Concurrency finally finalized in JDK 28 after seven preview roundsInfoQ: “JEP 543, Structured Concurrency, has been integrated into JDK 28, bringing the StructuredTaskScope API in java.util.concurrent to final status... Finalization concludes the longest preview cycle of any Project Loom feature.”
SupportedStructuredTaskScope API reaches final status with no changes from JDK 27 previewInfoQ: “with no API changes from JDK 27's seventh preview.”
SupportedJEP 543, Structured Concurrency, has been integrated into JDK 28InfoQ: “JEP 543, Structured Concurrency, has been integrated into JDK 28”
SupportedThe API is now stable and usable without preview flags, requiring only a recompilation for teams already on JDK 27.InfoQ: “For codebases already on JDK 27, the migration comes down to recompiling without --enable-preview.”
SupportedStructured concurrency debuted as an incubator API in JEP 428 (JDK 19) and JEP 437 (JDK 20), then progressed through seven previews from JDK 21 to JDK 27.InfoQ: “Structured concurrency debuted as an incubator API in JEP 428 (JDK 19) and JEP 437 (JDK 20), then progressed through seven previews: JEP 453 (JDK 21), JEP 462 (JDK 22), JEP 480 (JDK 23), JEP 499 (JDK 24), JEP 505 (JDK 25), JEP 525 (JDK 26), and JEP 533 (JDK 27).”
SupportedTraditional ExecutorService and Future pipelines do not enforce those boundaries.InfoQ: “Traditional ExecutorService and Future pipelines do not enforce those boundaries: a parent method can return while subtasks continue running in the background, and a subtask failure surfaces only when a caller eventually invokes Future.get().”
SupportedThe API centers on StructuredTaskScope, a sealed interface opened through static factory methods.InfoQ: “The API centers on StructuredTaskScope<T, R, R_X extends Throwable>, a sealed interface opened through static factory methods rather than public constructors.”
SupportedThe open() factory returns a scope where join() waits for all subtasks to succeed, cancels the rest on the first failure, and throws ExecutionException.InfoQ: “The zero-argument open() factory returns a scope whose join() method waits for all subtasks to succeed, cancels the rest on the first failure, and throws ExecutionException.”
SupportedTeams coming from JDK 26 face more changes, including the replacement of FailedException with ExecutionException and removal of StructuredTaskScope.TimeoutException. The onTimeout() callback has been replaced by an abstract timeout() method.InfoQ: “Teams coming from JDK 26 have more to change. They will see FailedException replaced by ExecutionException... In addition, StructuredTaskScope.TimeoutException has been removed... and the onTimeout() callback has been replaced by an abstract timeout() method.”
SupportedThe finalization commit only removes preview annotations and changes no method signatures.InfoQ: “The finalization commit only removes the preview annotations and changes no method signatures”
SupportedJDK 28 is scheduled for general availability in March 2027.InfoQ: “JDK 28 is scheduled for general availability in March 2027.”
SupportedThe velo/structured-concurrency project already backports the JEP 543 API to JDK 25 and provides migration recipes.InfoQ: “The velo/structured-concurrency project already backports the JEP 543 API to JDK 25 and ships migration recipes for moving to the JDK classes after an upgrade.”