Explain the common misconception about thenApply vs thenApplyAsync ordering. Do the Async variants change the order in which dependent stages execute?

## Setup: what 'dependent stage' means When you write `cf.thenApply(f).thenApply(g)`, you create a *linear dependency chain*: `g`'s input is `f`'s output, and `f`'s input is `cf`'s value. By definition, `g` cannot start until `f` has produced a result. This ordering is **inherent to the data dependency** and has nothing to do with which method overload you used. ## What the `Async` suffix actually controls Each transformation comes in three forms: - **`thenApply(fn)`** — runs `fn` on **whatever thread completed the predecessor** (or, if the predecessor is already complete when you attach, possibly the *calling* thread, inline/synchronously). - **`thenApplyAsync(fn)`** — submits `fn` to the **default executor** (`ForkJoinPool.commonPool()`). - **`thenApplyAsync(fn, executor)`** — submits `fn` to **your** executor. So the suffix chooses the **execution thread / scheduling**, not the **order**. `g` still runs after `f` in all three cases. ## The misconception, stated and refuted > "If I use `thenApplyAsync` everywhere, the stages run in parallel / a later stage might finish first / order becomes non-deterministic." False, for a *linear chain*. A stage that depends on a prior stage's value is gated on that value. `thenApplyAsync` only means "when the predecessor completes, *resubmit* my callback to an executor (a scheduling hop, possibly a different thread) rather than running it on the completing thread." The *happens-before* order f → g is preserved. There's no overtaking. What *is* non-deterministic is **which thread** runs each stage and the **tiny scheduling latency** of the hop — not the *order of effects*. ## Where async genuinely matters 1. **Getting off a special thread.** If the predecessor completes on a thread you must not occupy — e.g. a Netty/event-loop thread, a UI thread, or a thread that will block — `thenApply` would run your callback *on that thread*. `thenApplyAsync(fn, pool)` moves it off. This is the real, important reason to choose Async. 2. **Moving blocking work to the right pool.** Pair Async with a *dedicated* executor so blocking callbacks don't run on a completing thread you care about (or the common pool). 3. **Avoiding deep synchronous recursion / stack depth.** Long non-async chains that complete inline can build deep stacks; the async hop breaks the recursion. 4. **Thread-confinement requirements.** Some libraries demand callbacks run on a specific executor. ## Where parallelism *actually* comes from Parallelism is about **independent** computations, not the Async suffix. To run things concurrently you create *separate* futures and combine them: ```java var a = CompletableFuture.supplyAsync(this::loadA, pool); var b = CompletableFuture.supplyAsync(this::loadB, pool); var combined = a.thenCombine(b, this::merge); // a and b ran concurrently ``` Here `loadA` and `loadB` have no data dependency, so they execute in parallel; `thenCombine` waits for both. `allOf(...)` generalizes this to many. A single `a.thenApplyAsync(...).thenApplyAsync(...)` chain is still sequential. ## Subtle related point: non-async inline execution Because `thenApply` can run *inline on the completing thread or even the calling thread*, two pitfalls follow: (a) heavy/blocking work in a non-async stage may execute on a thread you didn't expect (e.g. the one that called `complete()`); (b) attaching a non-async stage to an *already-completed* future runs it immediately on the current thread, which can surprise you. Choosing Async with an explicit executor removes this ambiguity. ## Mental model `Async` = "hand this callback to an executor instead of running it on the completing thread." It answers *where* (which thread), never *when relative to its siblings in a chain* (the data dependency fixes that). Want parallelism? Make the futures independent and combine them.