[concurrency-interest] CompletableFuture in Java 8
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
>> operations in Stream and would have preferred to only expose async
>> 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(...)).
Isn't the only reason why this works that they are both running on the
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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest