On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang <[email protected]> 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. --- 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. On Wed, Sep 21, 2016 at 2:25 PM, Benjamin Manes <[email protected]> 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...
