[concurrency-interest] We need to add blocking methods to CompletionStage!

Martin Buchholz martinrb at google.com
Thu Sep 22 21:27:01 UTC 2016

Thanks for the lesson, James!

On Wed, Sep 21, 2016 at 3:57 PM, James Roper <james at lightbend.com> wrote:

> On 22 September 2016 at 06:43, Martin Buchholz <martinrb at google.com>
> wrote:
>> What is happening instead is API providers not using CompletionStage as
>> return values in public APIs because of the lack of convenient blocking,
>> and instead returning CompletableFuture, which is a tragic software
>> engineering failure.
> Out of interest, which APIs are returning CompletableFuture rather than
> CompletionStage?  In the Play Framework Java API, we have embraced
> CompletionStage, we use it absolutely everywhere.  Likewise in Lagom
> Framework and the Java API for Akka streams.
> When it comes to blocking, we strongly advocate never blocking (in the
> threading models of these projects, blocking on a future will make you very
> prone to deadlocks).

I took a look at the Scala/Akka/LightBend world.  Even there, blocking
always remains a possibility, even if discouraged, e.g.
scala.concurrent.Future extends Awaitable (!), and
And any general purpose Java API needs to be useful outside of a framework.

>   But of course, the exception is junit tests, in that case, we encourage
> the use of CompletionStage.toCompletableFuture to block.

We're currently fixing jdk9
CompletableFuture.minimalCompletionStage().toCompletableFuture() to be

To make toCompletableFuture().join() more reliable as a recommended way to
block, I think we should remove the encouragement to throw UOE from:

It sounds like the Akka/LightBend World is happy with current
CompletionStage API (may I call this the "actor purist API"?), while other
users will want a bigger, more general CompletableFuture subset for
consuming future values.  Frustratingly, some of them will want cancel(),
some not; and we have no good names for any new interfaces; right now all I
can think of is CompletionStage2 and CompletionStage3 !)

The current implementation of CompletableFuture has a "memory leak problem"
in that e.g. minimalStage().toCompletableFuture().isDone() will leak a
Completion object until the source stage itself is collected.  Which
doesn't happen if e.g. a direct isDone() is provided.
JDK-8161600: Garbage retention when source CompletableFutures are never
(but no one has ever complained!)

More information about the core-libs-dev mailing list