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

[Martin Buchholz]

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
http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#Blocking_Needs_Careful_Management
.
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
awaitable.

To make toCompletableFuture().join() more reliable as a recommended way to
block, I think we should remove the encouragement to throw UOE from:
http://download.java.net/java/jdk9/docs/api/java/util/concurrent/CompletionStage.html#toCompletableFuture--

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
completed
(but no one has ever complained!)