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