[steve-aom-elliott]

What's changed

Adds FindCompletableFutureDefaultExecutor, a search recipe. It marks:

• CompletableFuture / CompletionStage *Async(..) calls without a trailing Executor argument (supplyAsync, runAsync, thenApplyAsync, thenComposeAsync, thenCombineAsync, whenCompleteAsync, completeAsync, …).
• CompletableFuture.delayedExecutor(long, TimeUnit) without a base executor.
• Any of the above that pass ForkJoinPool.commonPool() explicitly. Before JDK 25, CompletableFuture substituted an explicit commonPool() with the thread-per-task fallback too, and JDK 25 removed that substitution.

What's your motivation?

JDK 25 changed CompletableFuture's default async executor:

JDK	Default async executor
8–24	commonPool(), or thread-per-task if parallelism ≤ 1
25	ForkJoinPool.asyncCommonPool(), no fallback

On a host with ≤ 2 CPUs, common-pool parallelism is 1, and asyncCommonPool() only adjusts it when it is 0. Blocking work (JDBC, HTTP) submitted without an Executor therefore used to get a fresh thread per task, but on JDK 25 it queues behind a single worker. Small containers are common, so this can cause large latency regressions after an upgrade with no code change.

Anything in particular you'd like reviewers to focus on?

• The recipe is standalone. It isn't added to UpgradeToJava25, because no Java upgrade composite currently includes a pure search recipe. Happy to add it there if preferred.
• The recipe doesn't attempt an automatic fix, because the right executor depends on the workload.
• Known false positive: subclasses of CompletableFuture that override defaultExecutor().
• In a call chain, the marker prints at the start of the chain. That's why the message names the flagged method.

[timtebeek]

Thanks! Few small changes & added it to the larger composite, as the search result marker won't end up on committed changes (for CLI) anyway. Plugin users who see this will want to consciously choose an executor.