[concurrency-interest] CompletableFuture in Java 8

√iktor Ҡlang viktor.klang at gmail.com
Sat Dec 13 15:05:50 EST 2014


On Sat, Dec 13, 2014 at 4:17 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/12/2014 05:04 PM, √iktor Ҡlang wrote:
>
>> On Fri, Dec 12, 2014 at 9:44 PM, thurstonn <thurston at nomagicsoftware.com
>> <mailto:thurston at nomagicsoftware.com>> wrote:
>>
>> So to answer (sort of) your question: I am not a fan of the blocking
>> terminal
>> operations in Stream and would have preferred to only expose async
>> terminal
>> operations (returning a CompletionStage). Perhaps we can get `async`
>> versions of
>> them for Java 9? (I assume deprecating the blocking ones is going to be a
>> hard sell)
>>
>>
> It would be nice to simplify mixed usages across the various styles
> discussed on this and related threads, but this one is relatively
> straightforward even now:
>
> CompletableFuture.supplyAsync(() -> data.parallelStream().reduce(...)).
>   thenApply(...);
>

Isn't the only reason why this works that they are both running on the
commonPool?
The question is how many uses of this to avoid blocking exists in the wild.


>
> (And some variants.)
>
> Any further integration would require internal conversions from
> the pull-style demand-driven lazy pipelines in j.u.Stream to
> push-style async. Considering that the manual version is straightforward,
> there's not much motivation for it. Although possibly some sugaring
> in the still-under-contemplation CompletionStages util class would
> be worthwhile.
>

Wouldn't it be possible to turn it around, and having the blocking terminal
methods call the async terminal methods and then block on the result?


>
> As I've mentioned, accommodating the opposite direction of push-style
> reactive to j.u.Stream is more important but also more challenging,
> in part because so much of it is out of our hands in j.u.c:
> For each kind of source, you need a reactive async alternative to
> standard blocking APIs. At the moment, it seems that the best we
> can do is add some utilities to simplify their creation:
> Simpler ties from nio2 to CompletionStages: standardized
> ways of batching (the opposite of splitting), and so on.


Perhaps a java.util.stream.nio with integration for reactive async for the
nio package?


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



-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141213/f2a257d5/attachment.html>


More information about the Concurrency-interest mailing list