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

[James Roper]

On 23 September 2016 at 07:27, Martin Buchholz <martinrb at google.com> wrote:

> Thanks for the lesson, James!
>
> 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.
>

Yes absolutely - personally I'm not against putting join on CompletionStage
(I'm happy to leave the disagreement of this to Viktor), my main concern
regarding CS/CF is encapsulation - if a library performs an asynchronous
computation, that library should be able to safely return a future of that
(using the term future here in the general sense) to clients and remain in
control of it, without worrying about what the clients will do with it -
the future should be effectively "immutable" from the clients perspective,
that is to say, the client shouldn't be able to change it's behaviour at
all.  For example, we often cache futures and return them from a libraries
API, if a client could cancel a future, that would break everything else
that received that future.  We'd rather not have to be in a situation where
to build a resilient API, we have to "copy" every future before we return
it, like APIs currently have to do with the Java collections API.


>   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!)
>



-- 
*James Roper*
*Software Engineer*

Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>