On 21 September 2016 at 22:43, Martin Buchholz <marti...@google.com> wrote:
Advertising
> (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
