Virtual threads gave Java scale. Structured concurrency gives it correctness. Here is why the second half of Project Loom quietly matters more — and what JEP 505 / JEP 525 actually change.
When Java 21 shipped virtual threads (JEP 444), the Java community collectively exhaled. Finally — cheap, blocking I/O without the ceremony of thread pools or the callback spaghetti of reactive frameworks. Naturally, that headline grabbed all the attention. However, there is a quieter companion feature that arguably matters even more for the everyday reliability of your code: Structured Concurrency.
First introduced as an incubator module in JDK 19 via JEP 428, structured concurrency is currently in its sixth preview in JDK 26 as JEP 525. The fifth preview — JEP 505 in JDK 25 — introduced the most substantial API changes so far, and the JDK 26 iteration polishes them further. Finalization is widely expected before the end of 2026, likely in JDK 27. In short: now is exactly the right time to understand what this feature actually solves.
1. The problem virtual threads don’t solve
Virtual threads are a performance and ergonomics story. They let you write synchronous-looking code that scales like asynchronous code, simply because parking a virtual thread costs almost nothing. That is genuinely great — but it does not touch the correctness problem.
Correctness problems in concurrent code are things like: a subtask running past its useful life because nobody told it to stop; an exception in one branch leaving other branches silently orphaned; a thread dump that shows you dozens of threads with no clue which request they belong to. These bugs exist just as much with virtual threads as they did with platform threads. In fact, because virtual threads are so cheap to create, it becomes even easier to accidentally spawn work with no clear owner.
Virtual threads solve the question “how many?” Structured concurrency solves the question “who is responsible?” Both questions matter, and only together do you get software that is both scalable and correct.
To make this concrete, consider the classic fan-out pattern: you handle a request by firing off two subtasks — say, fetching user data and fetching order data — and then combining the results. With an ExecutorService and Future, this is deceptively simple to write and deceptively hard to get right. As the JEP 505 specification states directly, ExecutorService and Future allow unrestricted patterns of concurrency: one thread can create the executor, a second can submit work to it, and a third can await results. There are no enforced relationships between any of those threads.
1.1 Three traps hiding in plain sight
Even straightforward ExecutorService fan-out code carries at least three structural hazards that most developers do not notice until something goes wrong in production:
| Hazard | What happens | Detectable at compile time? | Structured Concurrency fixes it? |
|---|---|---|---|
| Thread leak | Subtask keeps running after the parent exits, consuming memory and CPU silently | No | Yes |
| Cancellation delay | Sibling task does unnecessary work after another sibling has already failed | No | Yes |
| Opaque thread dumps | Debugging tools show a flat list of threads with no indication of which request each belongs to | No | Yes |
| Error swallowing | An exception in a subtask is silently ignored because the parent already moved on | No | Yes |
| Manual coordination boilerplate | Developers must hand-write try/finally cancel logic, which is error-prone and obscures intent | Partially | Yes |
2. What structured concurrency actually is
The idea comes from structured programming — the insight, back in the 1960s, that arbitrary goto jumps made code impossible to reason about, and that replacing them with blocks, loops, and functions made programs far more tractable. Structured concurrency applies the same insight to threads: if you start a group of related tasks together, you should also finish them together. They succeed or fail as a unit.
“Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.”
The mechanism is the StructuredTaskScope class in java.util.concurrent. You open a scope, fork subtasks into it, join them as a unit, and the scope’s lifetime is strictly bounded by the enclosing code block — just like a try block. When the scope closes, every subtask that was forked into it is guaranteed to have either completed or been cancelled. No exceptions, no orphans, no leaks.
The structural guarantee: A task cannot outlive its parent. This single constraint eliminates the entire class of thread-leak bugs structurally, at the API design level, rather than through developer discipline.
3. The long road to finalization
Structured concurrency has had one of the longest preview journeys in modern Java history, spanning seven JDK releases. Each iteration has refined the API based on real developer feedback — and the patience has produced something notably more ergonomic than the original design. Below is the full timeline, plus a comparison of where the complexity cost stands today versus the unstructured alternative.
JDK 19 · JEP 428
First incubator release. Basic StructuredTaskScope with ShutdownOnFailure and ShutdownOnSuccess subclasses.
JDK 20 · JEP 437
Re-incubated. Minor update to inherit scoped values. Scoped values link propagated to subtasks.
JDK 21 · JEP 453
First preview in java.util.concurrent. fork() now returns a Subtask handle instead of a Future.
JDK 22–24 · JEPs 462, 480, 499
Three re-preview cycles gathering production feedback. API surface largely stable.
JDK 25 · JEP 505 — Major API Overhaul
Public constructors replaced with static factory methods (StructuredTaskScope.open()). ShutdownOnFailure / ShutdownOnSuccess removed, replaced by a flexible Joiner interface. Policy and outcome now selected via Joiner argument.
JDK 26 · JEP 525 — Current
New Joiner.onTimeout() method. join() now returns a List instead of a Stream. anySuccessfulResultOrThrow() renamed to anySuccessfulOrThrow(). Minor, polish-level changes.
JDK 27 · JEP 533 — Proposed
Additional type parameter for exception type on join(). Finalization expected before end of 2026. API complexity to handle failure + cancellation correctly: structured vs unstructured
4. What JEP 505 and JEP 525 actually change
The most significant shift from JEP 505 (JDK 25) is the introduction of the Joiner interface, which cleanly separates two concerns that were previously tangled together: what policy do we apply when subtasks complete? and what result does the scope produce?
Previously, you would subclass StructuredTaskScope to override its completion policy. That approach coupled your business logic to the scope’s implementation detail. The new design is compositional: you pass a Joiner to StructuredTaskScope.open() and the scope’s behavior changes accordingly. This is a much cleaner separation of concerns, and it also makes custom policies far easier to write and test in isolation.
The built-in joiners
| Joiner | Behavior | Ideal use case |
|---|---|---|
Joiner.allSuccessfulOrThrow() | Waits for all subtasks. If any fail, cancels the rest and throws on join(). Returns a List of results. | Fan-out where every result is required (e.g. user + order + inventory) |
Joiner.anySuccessfulOrThrow() | Returns as soon as the first subtask succeeds. Cancels remaining tasks. | Racing multiple backends or mirror servers for lowest latency |
Joiner.awaitAll() | Waits for all subtasks regardless of outcome. No automatic cancellation. | Cleanup or audit tasks where every subtask must run to completion |
Joiner.allUntil(predicate) | Cancels remaining subtasks when the predicate returns true on a completed subtask. | Custom early-exit policies; partial result collection |
Custom Joiner implementation | Full control via onComplete() and result() hooks. | Domain-specific concurrency policies not covered by built-ins |
Meanwhile, JEP 525 (JDK 26) added Joiner.onTimeout() — a genuinely useful addition. Previously, handling timeouts required implementing a custom Joiner. Now, you can plug timeout behaviour directly into the standard joiners without any extra ceremony. This is a small surface change, but it plugs a real ergonomic gap.
Thread dump readability in production debugging: structured vs unstructured concurrency
5. How virtual threads and structured concurrency fit together
It is important to understand that these two features are complementary, not competing. The JEP 444 documentation itself puts it plainly: virtual threads deliver an abundance of threads, while structured concurrency correctly and robustly coordinates them.
Think of it this way: virtual threads remove the cost of threads. Structured concurrency removes the risk of threads. You need both. A system built on virtual threads alone can still leak threads, swallow exceptions, and produce unreadable thread dumps — it just does so with much lower memory overhead than before.
Additionally, structured concurrency integrates naturally with Scoped Values (JEP 506) — the modern replacement for thread-local variables. Subtasks forked inside a scope automatically inherit scoped value bindings from the parent. This means things like request IDs, authentication context, or tracing spans flow correctly into every subtask without any extra wiring — a significant win for observability.
6. When structured concurrency is not the right tool
It is worth being clear about the boundaries here, because the JDK team is explicit: it is not a goal of this feature to replace CompletableFuture or ExecutorService. That is not diplomatic hedging — it reflects a real design boundary.
Structured concurrency is a poor fit when: tasks are genuinely independent with no semantic parent-child relationship; you need to compose asynchronous pipelines functionally; you need streaming with back-pressure (channels are explicitly out of scope for JEP 505); or you are building a library API that returns futures for callers to compose in ways you cannot predict.
Furthermore, mixing StructuredTaskScope and raw CompletableFuture in the same logical operation is an anti-pattern worth naming explicitly. If a forked subtask internally creates an unmanaged CompletableFuture that escapes the scope, you have reintroduced exactly the lifetime management problem you were trying to eliminate. The safety guarantees of structured concurrency are transitive only if all concurrent work inside a scope is forked into it.
7. The observability bonus: thread dumps that actually make sense
This is perhaps the most underrated architectural implication of structured concurrency. Because StructuredTaskScope builds a runtime tree of tasks that mirrors the code’s logical hierarchy, thread dumps become genuinely readable — possibly for the first time in Java’s history.
When you run jcmd <pid> Thread.dump_to_file -format=json, the output groups threads by their scope, shows the parent-child relationships, and makes it immediately clear which HTTP request each thread belongs to and whether it is still doing useful work. In an ExecutorService-based system, a thread dump under load just shows you dozens of threads doing various things, with no way to tell which request they belong to or whether they are still relevant.
This is not a cosmetic improvement. In practice, a readable thread dump can cut debugging time for production incidents from hours to minutes. Structured concurrency gives you that for free, simply as a consequence of enforcing correct structure in the first place.
8. What we have learned
Throughout this article, we have seen that virtual threads solved Java’s scalability story by making threads cheap enough to use one per task, but that they left the correctness and observability problems entirely unaddressed. Structured concurrency, now in its sixth preview as JEP 525 in JDK 26 and approaching finalization in JDK 27, fills exactly that gap — by making it structurally impossible to leak threads, silently orphan tasks, or swallow exceptions, and by making thread dumps readable enough to actually debug production incidents.
We explored how JEP 505 introduced the Joiner interface as the API’s most substantial redesign, cleanly separating completion policy from scope management, and how JEP 525 (JDK 26) added small but important refinements like onTimeout() and a cleaner join() return type. We also looked at where CompletableFuture and ExecutorService still belong — because the goal is never to replace every concurrency primitive, but to use the right tool for each job.
Altogether, virtual threads and structured concurrency are two halves of a single answer to concurrent Java. One gives you scale. The other gives you correctness. Together, they represent the most significant upgrade to Java’s concurrency model in two decades — and it is worth getting familiar with both before JDK 27 makes it official.
