Skip to content

Commit 855b0ce

Browse files
authored
Update ARTICLE1.md
1 parent ade3079 commit 855b0ce

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

ARTICLE1.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -141,7 +141,7 @@ CompletionStage<String> p4 = p3.thenApplyAsync(this::transformValueC);
141141
The call to `produceValue` will be executed on the `executorInitial`, obviously. But now, the call to `transformValueA` will be executed also on `executorInitial`! What's about deeper calls? The invocation to `transformValueB` ran on explicitly supplied `executorNext`. And next call, `transformValueC` will be executed on... check your intuition... `executorNext`. The logic behinds this is the following: the latest explicitly specified `Executor` is what will be used for all nested asynchronous composition methods without an explicit `Executor` parameter.
142142

143143
Obviously, it's rarely the case when one size fits all. therefore two additional options exist to specify default asynchronous executor:
144-
1. `CompletableTask` has an overloaded method:
144+
1. A. `CompletableTask` has an overloaded method:
145145
```java
146146
public static Promise<Void> asyncOn(Executor executor, boolean enforceDefaultAsync)
147147
```

0 commit comments

Comments
 (0)