CompletableFuture (original) (raw)

David M. Lloyd david.lloyd at redhat.com
Wed Nov 28 09:11:38 PST 2012

On 11/28/2012 11:03 AM, Doug Lea wrote:

On 11/28/12 11:09, Remi Forax wrote:

The void completion methods don't return new CompletableFuture (no need) but just "return this" to be nice to fluency fans. aaaaaah, It means that with CompletableFuture c = completableFuture.then(e -> foo(e)); c.isDone() can be true even if foo() has still not finished. Having a fluent interface is a nice trick but here, the resulting semantics is too weird IMO. Thanks. Good point. I initially defined these as void (as opposed to the Function ones, that return a new one to maintain value). Changing to "return this" makes them much simpler to use but as you point out makes it look like the "." in a compound expression refers to the wrong thing. I guess the best way out is to actually create/return a little CompletableFuture here, which doesn't appreciably inflate cost and precludes misinterpretation. So... /** * Creates and returns a CompletableFuture> that is completed * after performing the given action with the result of this * CompletableFuture if/when it completes normally. * * @return the new CompletableFuture */ public CompletableFuture then(Block<? super T> action); And similarly for and(), or(), exceptionally(). We still have the function vs action method overriding issue though.

Maybe this is getting a bit to abstract, but anecdotally speaking we have found that "do A then B" is "less good" than "do B when A is done", i.e. model the problem in terms of tasks and their dependencies rather than as a sequential chain of tasks to run in order. It's just inherently cleaner and potentially more performant (any given task can execute as soon as its dependencies are satisfied; there are no artificial sequences imposed on tasks). But, at the same time, that mode of thinking seems to be fairly incompatible with Future.

--

More information about the lambda-libs-spec-observers mailing list