RFR 9: 8077350 Process API Updates Implementation Review
Peter Levart
peter.levart at gmail.com
Fri May 15 12:31:20 UTC 2015
Hi Roger,
On 05/15/2015 12:35 PM, Peter Levart wrote:
> public class AsyncCompletableFuture ... {
>
> /**
> * Returns a new CompletionStage that, when this stage completes
> * normally, completes with the given replacementResult.
> *
> * @param replacementResult the successful completion value of the
> returned
> * CompletionStage
> * @param <U> the value's type
> * @return the new CompletionStage
> */
> public <U> AsyncCompletableFuture<U> thenReplace(U
> replacementResult) { ...
>
> I can ask on the concurrency-interest list about the feasibility of
> such [Async]CompletableFuture split. Would you be interested in using
> AsyncCompletableFuture if it was available?
...on a second thought, .xxxAsync(..., Executor) methods on
[Async]CompletableFuture do not necessarily attach just asynchronous
continuations if a SynchronousExecutor passed as Executor parameter, so
we wouldn't get any guarantee of thread isolation. Only exposing
xxxAsync() methods without custom Executor on the other hand precludes
the possibility of supplying a custom executor.
Sorry, but this was not a good idea.
Regards, Peter
More information about the core-libs-dev
mailing list