[concurrency-interest] CompletableFuture in Java 8

√iktor Ҡlang viktor.klang at gmail.com
Mon Dec 1 05:07:35 EST 2014

On Sun, Nov 30, 2014 at 4:42 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 11/27/2014 10:45 PM, Josh Humphries wrote:
> A few notes not covered in other responses...
>> Below are some of my nits about the Java8 APIs:
>> I disagree with how the CompletionStage interface is so tightly coupled to
>> the CompletableFuture implementation. Why does CompletionStage have a
>> toCompletableFuture() method? It feels like the interface should instead
>> have
>>  just extended Future.
> Viktor recapped the good arguments for not extending Future. But
> we still needed a standard means for interoperable implementations to
> extract values. Method toCompletableFuture() is the simplest way to get
> this effect by anyCompletableFuture developer (usually a one-liner),
> and is marked as optional in case they don't care about interoperability.

I agree from a discoverability-perspective, even if I'd rather had seen a
CompletableFuture.fromStage(stage) method as to keep the generic part
oblivious of the implementation.

>> I dislike that the only CompletionStage implementation in the JRE,
>> CompletableFuture, is like Guava's SettableFuture -- where the result is
>> set
>>  imperatively. This has its uses for sure. But an implementation whose
>> result
>>  comes from executing a unit of logic, like FutureTask
>> (CompletionStageTask?), is a glaring omission.
> The goal was to provide a robust, efficient base implementation supporting
> all reasonable usage policies. We expected more cases of delegation
> for frameworks with restricted policies (similarly for obtrude*).
> This hasn't happened much yet.

You mean delegation as in wrapping?

>  1. They don't allow interruption of the task when the future is cancelled.
>  3. They don't support scheduling the task for deferred execution (like in
>> a
>> ScheduledExecutorService).
> In most cases, this is the same issue: You'd like to
> somehow remove/suppress a cancelled timeout or timer-generated action
> upon cancellation, mainly for the sake of resource-control.
> Most other cases reduce to the mixed sync/async usage issues
> mentioned in other posts, that we cannot do much about in j.u.c itself.
> In retrospect, maybe we should have added a few static methods and
> a default internal static ScheduledExecutor to support these usages,
> since everyone seems to need them. One reason we didn't is that
> these further invite defining methods producing streams of periodic
> CFs, which leads to further APIs bridging CFs with streams/observables,
> which we triaged out of jdk8 (see my other posts on this.)
> Still, something along these lines (perhaps just a class with
> static CF utility methods) should be added.

Perhaps this is the perfect time for a j.u.c2? With all we've learned the
past 10-15 years :-)

> On 11/28/2014 11:57 AM, √iktor Ҡlang wrote:
>  Now, my preference would be to have removed the 3 versions of every method
>> (x, xAsync, xAsync + Executor) and instead only have `x` + Executor and
>> then
>> you can supply a CallingThreadExecutor, ForkJoinPool.commonPool() or
>> <custom>
>> and you get exactly the same behavior without the interface pollution.
> If the API were expressed in a language with implicits, this might have
> been more tempting. (Well, except that everyone would then instead
> be complaining about implicits :-)

Lol! Well, that is certainly true, however, we seem to fare pretty well
with a Java API that takes an Executor  (ExecutionContext) for all
"deferred" operations. There's also the choise of having a bind-method so
you could treat it as a Stream of sorts:

future.bind(executor).operation1(…).operation2(…).terminalOperation(/* no
evaluation happens until here*/)

> Also, it there were a Unit type,
> the API would shrink by almost a factor of three
> (Runnable as Unit->Unit etc).

Yes, sadly Void has no value :) (the cause of much irregularities since day

> But the variants are regular enough that users don't seem to
> complain about any of them in particular, only of the resulting
> too-bigness feeling.
> On the other hand, it does look overly imposing to developers of
> layered/delegated classes. Adding default implementations using
> lambda-based function adaptors might be a good idea, but it is
> probably too late for that in CompletionStage itself. We could
> add class AbstractCompletionStage though.

AbstractCompletionStage sounds like a great idea to accelerate adoption of
we should explore that option.

> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

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

More information about the Concurrency-interest mailing list