If that truely is the case then the only way of implementing a readonly Future is by throwing an exception from cancel...
-- Cheers, √ On Sep 25, 2016 4:20 PM, "Joe Bowbeer" <joe.bowb...@gmail.com> wrote: > This statement regarding what happens after cancel is called is correct: > > "*After this method returns, subsequent calls to **isDone**() will always > return true*. Subsequent calls to isCancelled() will always return true > if this method returned true." > > After cancel returns, the future is completed, hence isDone. If cancel > returns true, i.e. it was cancelled, then isCancelled returns true. But, > for example if the future is already completed when cancel is called, then > cancel will return false and isCancelled will return false. > > On Sep 25, 2016 6:49 AM, "David Holmes" <davidchol...@aapt.net.au> wrote: > >> I think that was meant to read “After this method returns _*true*_, >> subsequent calls …” >> >> >> >> David >> >> >> >> *From:* Concurrency-interest [mailto:concurrency-interest-b >> oun...@cs.oswego.edu] *On Behalf Of *Viktor Klang >> *Sent:* Sunday, September 25, 2016 9:03 PM >> *To:* Martin Buchholz <marti...@google.com> >> *Cc:* concurrency-interest <concurrency-inter...@cs.oswego.edu>; >> core-libs-dev <core-libs-dev@openjdk.java.net> >> *Subject:* Re: [concurrency-interest] We need to add blocking methods to >> CompletionStage! >> >> >> >> >> >> >> >> On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang <viktor.kl...@gmail.com> >> wrote: >> >> >> >> >> >> 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/concurre >> nt/Future.html >> >> >> >> There's an interesting (read: weird) spec clause in cancel: >> >> >> >> "*After this method returns, subsequent calls to isDone() will always >> return true*. Subsequent calls to isCancelled() will always return true >> if this method returned true." >> >> >> >> That clause is in contradiction with the previously quoted line. >> >> >> >> >> >> >> >> >> >> 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, >> >> √ >> >> >> >> >> >> -- >> >> Cheers, >> >> √ >> >> _______________________________________________ >> Concurrency-interest mailing list >> concurrency-inter...@cs.oswego.edu >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> >>
