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

Martin Buchholz martinrb at google.com
Sat Sep 24 16:41:46 EDT 2016


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 <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/20160924/0c56005c/attachment.html>


More information about the Concurrency-interest mailing list