[concurrency-interest] We need to add blocking methods to CompletionStage!

Viktor Klang viktor.klang at gmail.com
Sun Sep 25 06:34:58 EDT 2016

On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz <martinrb at google.com>

> 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.

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

"This attempt will fail if the task has already completed, has already been
cancelled, *or could not be cancelled for some other reason.*"


>   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 <james at 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.klang at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160925/8edd1baf/attachment.html>

More information about the Concurrency-interest mailing list