[concurrency-interest] CompletableFuture improvements

Doug Lea dl at cs.oswego.edu
Fri Aug 14 11:33:11 EDT 2015

On 08/14/2015 06:48 AM, Chris Purcell wrote:
> I have a few suggestions for changes that could be made to CompletableFuture,

Thanks! Answering out of order...

> (2) CompletionStage.whenComplete discards exceptions if both input stage and
> action fail. It would be less surprising if, like try/finally, it added the
> action exception to the input exception as a suppressed exception.

This seems like a good idea, that we would have done if it had
crossed anyone's mind!  And it can be done now without any
loss of compatibility. Pending any near-term objections, I'll
try incorporating this.

> (1) Internally, CompletableFuture's fluent API constructs a work queue of
> callbacks to execute, to avoid StackOverflowErrors caused by callback
> recursion, but there is no way to add custom tasks to it.

I think I'm missing the underlying functionality requirement here.
Can you sketch out some use cases, and how they should be handled?

> (3) CompletableFuture uses concurrent assistance to execute its callback
> queue.

Which some users do exploit by creating multiple independent continuation
tasks. (In fact CompletableFuture is computationally complete as a
concurrency primitive -- you can in principle write any concurrent
program only using it). We can't remove this functionality. But
it would be fine to have other CompletionStage implementation classes
that don't support branching parallelism. Especially one that helps
bridge guava ListenableFuture.

> My assumption may be way off-base here, though. Are there other reasons for
> the two-field approach of CompletableFuture?

Notice that Signallers for threads blocked waiting for completion are
also held in the linked stack. There may be some good alternative.


More information about the Concurrency-interest mailing list