Setting of UNORDERED on concurrent collectors

[Joe Bowbeer]

What is groupingByConcurrent good for?  What's the difference between
parallel and concurrent in this context?

I've re-read the last 5 emails that mention groupingByConcurrent and it is
not clear to me what's going on.

The most succinct indication of its function is:

The collect(Collector) method currently performs a concurrent collection
> when all of the following are true:
>  - the stream is parallel
>  - the collector is *concurrent*
>  - the collector is unordered OR the stream is unordered


In other words, *if* I happen to use groupingByConcurrent *then* maybe a
concurrent collection will be performed, but maybe not, depending on a
couple other factors...

Can we make this simpler and more intuitive/predictable?  I realize that's
what you're addressing now, but can't we go a lot farther?

Can we, say, get rid of groupingByConcurrent and just assume that if the
stream is parallel?  What do we lose?  Do we lose any functionality that
can't be derived another way?

Please educate me!

--Joe


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

> Now that we've removed collectUnordered in favor of a more general
> unordered() op, we should consider what should be the default behavior for:
>
>   orderedStream.collect(**groupingByConcurrent(f))
>
> Currently, the collect-to-ConcurrentMap collectors are *not* defined as
> UNORDERED.  Which means, if the stream is ordered, we will attempt to do an
> ordered collection anyway, which is incompatible with concurrent
> collection, and we will do the plain old partition-and-merge with
> ConcurrentMap.
>
> Here, we have competing evidence for the user intent.  On the one hand,
> the stream is ordered, and the user could have chosen unordered.  On the
> other, the user has asked for concurrent grouping.  Its not 100% obvious
> which should win.
>
> On the other hand, ordered map collections are so awful that they will
> almost certainly be unhappy with the performance if they forget to say
> unordered here in the parallel case (and it makes no difference in the
> sequential case.)  So I'm inclined to make groupingByConcurrent /
> toConcurrentMap be UNORDERED collections.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130408/90b8808e/attachment.html