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

[James Roper]

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).  But of course, the exception is junit tests, in that
case, we encourage the use of CompletionStage.toCompletableFuture to
block.  In these projects, you'll generally encounter two different
implementations of CompletionStage, one is CompletableFuture, the other is
a scala.concurrent.Future backed implementation.  Both implement
toCompletableFuture.  But a user that integrates a third party library with
its own CompletionStage implementation of course may encounter issues, that
said, I haven't yet seen many (or any?) libraries outside of our ecosystem
that are embracing CompletionStage or CompletableFuture in their public
APIs yet (this is probably due to my ignorance, not due to there not being
any), which is part of why I'm interested in knowing what libraries you
know of that are using it.

Re-adding join is easy.  We discourage CompletionStage.toCompletableFuture
> from throwing UnsupportedOperationException, and implement join as:
>
>     public default T join() { return toCompletableFuture().join(); }
>
> There is a risk of multiple-inheritance conflict with Future if we add
> e.g. isDone(), but there are no current plans to turn those Future methods
> into default methods, and even if we did in some future release, it would
> be only a source, not binary incompatibility, so far less serious.
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
*James Roper*
*Software Engineer*

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