| 33 |
|
* {@link #cancel cancel} |
| 34 |
|
* a CompletableFuture, only one of them succeeds. |
| 35 |
|
* |
| 36 |
< |
* <p>Methods are available for adding dependents based on Functions, |
| 37 |
< |
* Consumers, and Runnables. The appropriate form to use depends on |
| 38 |
< |
* whether actions require arguments and/or produce results. Actions |
| 39 |
< |
* may also be triggered after either or both the current and another |
| 36 |
> |
* <p>Methods are available for adding dependents based on |
| 37 |
> |
* user-provided Functions, Consumers, or Runnables. The appropriate |
| 38 |
> |
* form to use depends on whether actions require arguments and/or |
| 39 |
> |
* produce results. Completion of a dependent action will trigger the |
| 40 |
> |
* completion of another CompletableFuture. Actions may also be |
| 41 |
> |
* triggered after either or both the current and another |
| 42 |
|
* CompletableFuture complete. Multiple CompletableFutures may also |
| 43 |
|
* be grouped as one using {@link #anyOf(CompletableFuture...)} and |
| 44 |
|
* {@link #allOf(CompletableFuture...)}. |
| 45 |
|
* |
| 46 |
< |
* <p>Actions supplied for dependent completions (mainly using methods |
| 47 |
< |
* with prefix {@code then}) may be performed by the thread that |
| 48 |
< |
* completes the current CompletableFuture, or by any other caller of |
| 49 |
< |
* these methods. There are no guarantees about the order of |
| 50 |
< |
* processing completions unless constrained by these methods. |
| 46 |
> |
* <p>CompletableFutures themselves do not execute asynchronously. |
| 47 |
> |
* However, actions supplied for dependent completions of another |
| 48 |
> |
* CompletableFuture may do so, depending on whether they are provided |
| 49 |
> |
* via one of the <em>async</em> methods (that is, methods with names |
| 50 |
> |
* of the form <tt><var>xxx</var>Async</tt>). The <em>async</em> |
| 51 |
> |
* methods provide a way to commence asynchronous processing of an |
| 52 |
> |
* action using either a given {@link Executor} or by default the |
| 53 |
> |
* {@link ForkJoinPool#commonPool()}. To simplify monitoring, |
| 54 |
> |
* debugging, and tracking, all generated asynchronous tasks are |
| 55 |
> |
* instances of the marker interface {@link AsynchronousCompletionTask}. |
| 56 |
> |
* |
| 57 |
> |
* <p>Actions supplied for dependent completions of <em>non-async</em> |
| 58 |
> |
* methods may be performed by the thread that completes the current |
| 59 |
> |
* CompletableFuture, or by any other caller of these methods. There |
| 60 |
> |
* are no guarantees about the order of processing completions unless |
| 61 |
> |
* constrained by these methods. |
| 62 |
|
* |
| 63 |
|
* <p>Since (unlike {@link FutureTask}) this class has no direct |
| 64 |
|
* control over the computation that causes it to be completed, |
| 83 |
|
* methods {@link #join()} and {@link #getNow} throw the |
| 84 |
|
* CompletionException, which simplifies usage. |
| 85 |
|
* |
| 73 |
– |
* <p>CompletableFutures themselves do not execute asynchronously. |
| 74 |
– |
* However, the {@code async} methods provide commonly useful ways to |
| 75 |
– |
* commence asynchronous processing, using either a given {@link |
| 76 |
– |
* Executor} or by default the {@link ForkJoinPool#commonPool()}, of a |
| 77 |
– |
* function or action that will result in the completion of a new |
| 78 |
– |
* CompletableFuture. To simplify monitoring, debugging, and tracking, |
| 79 |
– |
* all generated asynchronous tasks are instances of the marker |
| 80 |
– |
* interface {@link AsynchronousCompletionTask}. |
| 81 |
– |
* |
| 86 |
|
* @author Doug Lea |
| 87 |
|
* @since 1.8 |
| 88 |
|
*/ |
