[concurrency-interest] CompletableFuture in Java 8
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
>> 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
>> imperatively. This has its uses for sure. But an implementation whose
>> 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
> 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
>> you can supply a CallingThreadExecutor, ForkJoinPool.commonPool() or
>> 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:
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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest