Setting of UNORDERED on concurrent collectors

[Joe Bowbeer]

On Mon, Apr 8, 2013 at 2:09 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> That option is always available regardless of what we do with Collectors.
>
> Remember, where Collector really shines is not the simple things like
> this, but composite collections, like
>
>   Map<Buyer, Map<Seller, Transaction>>
>     biggestTransactionByBuyerSelle**r =
>       stream.collect(groupingBy(Txn:**:buyer,
>                                 groupingBy(Txn::seller,
>                                            maxBy(comparing(Txn::amount))
>
>
This is where groupingBy really shines :)

But how is someone supposed to decide if any or some or all of these
groupingBy's should really be groupingByConcurrent's?

If we eliminated groupingByConcurrent in favor of a more explicit form in
those cases, would that ruin the shine?

--Joe


> The groupBy combinator lets you compose complex collections out of
> building blocks.  These would have to be manually inlined with the explicit
> parallel forEach version.
>
>
>
> On 4/8/2013 4:57 PM, Doug Lea wrote:
>
>> On 04/08/13 16:41, Joe Bowbeer wrote:
>>
>>  I'm OK with this, but I wish groupingByConcurrent could go away.
>>>
>>>
>> These were the kinds of thoughts that led me last fall to suggest
>> that we just tell people to do it themselves as a little idiom:
>>    chm = ...
>>    c.parallelStream().forEach( chm.merge(x->keyFor(x), x, mergefn); }
>>
>> The main downside is that this, the most commonly recommended
>> way of doing parallel groupBy, would not be in the family of
>> collect methods. Still maybe worth reconsidering though.
>>
>> -Doug
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130408/8a5f88a3/attachment.html