No one is suggesting we add cancel to CompletionStage - I agree that would break users, by making an immutable interface mutable. This also means that CompletionStage cannot extend Future. I also would not want to have a toFuture method that would return a j.u.c.Future, because of misfit Future.cancel. If we are adding cancel, then it will be to make a new interface, such as the suggested CancellableCompletionStage.
I also agree that CompletionStage does *not* represent "a running task of sorts", j.u.c. Future specs are still confusing in that way due to FutureTask heritage. On Thu, Sep 22, 2016 at 7:51 PM, James Roper <[email protected]> wrote: > For example, we often cache futures and return them from a libraries API, > if a client could cancel a future, that would break everything else that > received that future. On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang <[email protected]> wrote: > PPS: A misunderstanding is that CompletionStage represents a running task > of sorts, one that can be cancelled etc. This is not the case. >
