Thanks for the lesson, James! On Wed, Sep 21, 2016 at 3:57 PM, James Roper <ja...@lightbend.com> wrote:
> On 22 September 2016 at 06:43, Martin Buchholz <marti...@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!)
