When would you choose structured concurrency over CompletableFuture or a shared ExecutorService, and what are its current limitations and adoption risks?

## The three tools - **`ExecutorService`** — a pool of worker threads you submit tasks to; returns `Future`s. General-purpose, long-lived, **unstructured** (task lifetimes aren't tied to the submitter). - **`CompletableFuture` (CF)** — an asynchronous *value* with combinators (`thenApply`, `thenCompose`, `allOf`, `anyOf`, `exceptionally`) for building **non-blocking pipelines**. The async computation is a first-class object you can store, pass around, and compose; it may outlive the method that created it. - **`StructuredTaskScope`** — a **block-scoped** group of subtasks with nested lifetimes, fork/join, policies, and propagation. **Request-scoped**, not free-floating. ## When structured concurrency wins Reach for it when the concurrency is **self-contained within one operation**: 1. **Fan-out within a request.** A handler needs user + orders + prefs from three services to build a response. Fork all three, join, aggregate, return. Lifetimes nest inside the handler. 2. **You want fail-fast + automatic cancellation.** Shutdown-on-failure cancels siblings on the first error; shutdown-on-success cancels losers on the first win. No manual `future.cancel(true)` bookkeeping. 3. **You want errors to surface to the caller** like a normal exception, handled with `try/catch`, not buried in a `Future`. 4. **Readability and observability matter.** The code is top-to-bottom sequential-looking; thread dumps show the parent/child tree; no leaked tasks. 5. **You're already on (or moving to) virtual threads.** Forking a *blocking* subtask per unit of work is cheap, so you keep simple blocking code instead of an async combinator graph. ## When CompletableFuture or ExecutorService is the better fit - **Long-lived / event-driven async pipelines** that outlive a single call, stream stages, or need to be **passed around and composed** as values → `CompletableFuture`. (A scope cannot escape its block.) - **Non-blocking, callback-style** designs already built on CF combinators → don't rewrite working code. - **A durable pool of unrelated background jobs** (schedulers, fire-and-forget workers) → a shared `ExecutorService` whose lifetime is the application, not one request. - **Pre-virtual-thread platform-thread budgets** where you deliberately bound concurrency with a fixed pool. ## The virtual-threads relationship **Virtual threads** are JVM-scheduled lightweight threads — millions are feasible because a blocked virtual thread doesn't pin an OS thread. Structured concurrency was co-designed with them: it gives the *discipline* (bounded lifetimes, cancellation) that makes "fork one blocking subtask per item" safe at scale. Without virtual threads you can still use scopes, but the headline ergonomic win (cheap blocking subtasks) is muted. ## Limitations & adoption risks (the principal-level core) 1. **Preview/incubating status.** The API has been a *preview* feature across JDK 21–25 and its **surface changed** — concrete `ShutdownOnFailure`/`ShutdownOnSuccess` subclasses gave way to a `Joiner`-based factory (`open(Joiner)`, `Joiner.allSuccessfulOrThrow()`/`anySuccessfulResultOrThrow()`). Building on it means accepting **source churn** between JDKs and possibly enabling preview flags. Mitigate by **wrapping it behind a thin internal abstraction** so call sites don't break when the surface shifts, and by **pinning the JDK**. 2. **Block confinement.** A scope can't be returned or stored as an async value; it must complete within its method. That's by design (it's what gives the guarantees) but it means it's **not a drop-in replacement for CF** where you need a passable future. 3. **Cancellation is cooperative.** Wins depend on subtasks honoring interruption; uninterruptible blocking/native calls delay `close()`. 4. **Owner-thread / structure rules.** fork-from-owner, join-before-read — a different mental model than free-form `Future` use; teams need to learn it. 5. **Ecosystem maturity.** Libraries/frameworks may not yet expose interruptible, scope-friendly APIs everywhere. ## A pragmatic adoption stance - Use structured concurrency for **new request-scoped fan-out**, especially alongside virtual threads. - **Wrap** the preview API behind a small internal helper to localize churn. - **Leave** stable CompletableFuture pipelines and long-lived executors as they are. - Ensure subtasks are **interruptible** so cancellation is prompt. - Track the JEP as it moves toward final, and plan a follow-up to drop preview flags once stabilized.