We need to add blocking methods to CompletionStage!

Kasper Nielsen kasperni at gmail.com
Fri Sep 23 06:45:42 UTC 2016

On 21 September 2016 at 22:43, Martin Buchholz <martinrb at google.com> wrote:

> (Sorry to re-open this discussion)
> The separation of a read-only CompletionStage from CompletableFuture is
> great.  I'm a fan of the scala style Promise/Future split as described in
> http://docs.scala-lang.org/overviews/core/futures.html, but: we need to
> re-add (safe, read-only) blocking methods like join.

Just want to say that I agree. I have using CS/CF for APIs extensively
since Java 8. And all my usage basically boils down to 3 basic use cases.
And I think most others will end up with the same use cases.

1) Observing
The user receives a CS where he can query about the state of the future and
add follow up actions. I really would like to see the rest of the
non-mutating methods from CompletableFuture added to CompletionStage here
if possible.
get(long, TimeUnit)
isCompletedNormally() (isDone && !isCompletedExceptionally) <- new method

2) Cancellable
Tasks that can be cancelled by the user but where the user should not be
able to modify the result or set a custom exception.
For example, cancel connecting to a remote host or cancel some internal

Right not this is a bit painfull. I have to wrap CompletableFuture to allow
cancel but hide complete/obtrude

Would not mind a CancellableCompletionStage interface
CancellableCompletionStage extends CompletionStage {

3) Mutable
The user has complete control. Basically just these three additional
methods compared to CancellableCompletionStage.
I'm fine with returning CompletableFuture here.


More information about the core-libs-dev mailing list