On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz <marti...@google.com> wrote:
> No one is suggesting we add cancel to CompletionStage - I agree that would > break users, by making an immutable interface mutable. > +10000 > This also means that CompletionStage cannot extend Future. > +10000 > I also would not want to have a toFuture method that would return a > j.u.c.Future, because of misfit Future.cancel. > Would you mind elaborating here? According to the cancel method spec on Future it is completely fine for it to be a no-op which always returns false: "This attempt will fail if the task has already completed, has already been cancelled, *or could not be cancelled for some other reason.*" Source: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html > 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. > +10000 > > On Thu, Sep 22, 2016 at 7:51 PM, James Roper <ja...@lightbend.com> 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 <viktor.kl...@gmail.com> > wrote: > >> PPS: A misunderstanding is that CompletionStage represents a running task >> of sorts, one that can be cancelled etc. This is not the case. >> > > > -- Cheers, √
