We need to add blocking methods to CompletionStage!

[Kasper Nielsen]

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()
get(long, TimeUnit)
getNow()
isCompletedExceptionally
isDone()
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
computation.

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 {
  isCancelled();
  cancel(boolean)
}

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

Best
  Kasper