[concurrency-interest] CompletableFuture in Java 8

Mohan Radhakrishnan radhakrishnan.mohan at gmail.com
Mon Dec 1 06:13:46 EST 2014


Hi viktor,
               I read what Gunther has published in his 'Guerilla' books.
Did you work with any USL calculations relating cores and the j.u.c.
threads ?

Thanks,
Mohan

On Mon, Dec 1, 2014 at 3:37 PM, √iktor Ҡlang <viktor.klang at gmail.com> wrote:

>
>
> 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 1)
>
>
>>
>> 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
> CompletionStage,
> we should explore that option.
>
>
>>
>>
>>
>> -Doug
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
>
> --
> Cheers,
>>
> _______________________________________________
> 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/b1d87d71/attachment-0001.html>


More information about the Concurrency-interest mailing list