On Sun, Sep 25, 2016 at 10:01 PM, Martin Buchholz <marti...@google.com> wrote:
> > > On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang <viktor.kl...@gmail.com> > wrote: > >> If that truely is the case then the only way of implementing a readonly >> Future is by throwing an exception from cancel... >> > We the maintainers of j.u.c.Future have always thought that canceling a > Future will surely leave it completed. Of course, implementers of any Java > interface can choose to throw UOE for any method, but this is not intended > for Future.cancel. An interface without cancel probably should not be > extending Future. > This seems to have been "addressed" further down this thread. > > --- > > Here's another way to think of the range of functionality between current > CompletionStage and current CompletableFuture: > > - Add Polling methods from scala Future such as isCompleted > <http://www.scala-lang.org/api/2.12.0-RC1/scala/concurrent/Future.html#isCompleted:Boolean> > These are also discouraged, but less so than Await methods > """Note: using this method yields nondeterministic dataflow programs.""" > Will adding these to CompletionStage be less controversial? > > - Add Await blocking methods (that in scala cannot be called directly, > using the CanAwait mechanism) > > - Add cancellation > > - Add other methods to complete the future ("Promise") > > - Add the full CompletableFuture API, including the obtrude methods > > Cancellation is interesting, because it's a mutating method, and so cannot > be used with a future shared with other users, but it also seems very > reasonable as a "client" operation. One can think of obtaining a > non-shared future as a subscription to a one-time event, and that > subscription takes up resources in the form of an object. If the client is > no longer interested in the event, then cancellation of the future can free > up resources. I'm still thinking of what Process.onExit > <http://download.java.net/java/jdk9/docs/api/java/lang/Process.html#onExit--> > should return. There's a tension between the various roles that > CompletableFuture serves - as a container to write a value, as a possibly > cancellable subscription to that value, and as a way to chain async > computations together. > I'd rather suggest creating a 2.0 of FutureTask (i.e. represent the Task part separately from the Future part) Have something represents something being executed somewhere else, that can support cancellation but also expose a read-only facet of itself. I think you're right in that something is missing which would lie somewhere in between CompletionStage and CompletableFuture. What methods would you propose to add to such an interface and why? > > On Wed, Sep 21, 2016 at 2:25 PM, Benjamin Manes <ben.ma...@gmail.com> > wrote: > >> I've gradually come to terms using CF as part of an API and haven't >> experienced a downside yet. >> > > Hmmmm.... I seem to be moving in that direction as well... > -- Cheers, √
