Setting of UNORDERED on concurrent collectors

[Paul Sandoz]

On Apr 16, 2013, at 9:47 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> We never converged on this one.  Here's another stab at framing the problem.  (I'm pretty much ready to time out and make these collectors declare UNORDERED unless someone can convince me otherwise.)
> 
> Streams consist of source + intermediate ops + terminal.
> 
> Denote ordered/unordered variants of these as SO/SU, IO/IU/IA (A=agnostic), and TA/TU.  We can define the ordered-ness of any stream pipeline as follows:
> 
> ordered(SO) = true
> ordered(SU) = false
> 
> ordered(X+IO) = true
> ordered(X+IU) = false
> ordered(X+IA) = ordered(X)
> 
> ordered(X+TA) = ordered(X)
> ordered(X+TU) = false
> 
> A concurrent calculation may be performed if the stream is unordered *and* the destination is concurrent.
> 
> Collectors like toSet() are marked TU, and toList() are marked TA. Collectors like groupingByConcurrent will definitely be marked concurrent.  Question is, should it be marked TA or TU?  Either choice is defensible.
> 

I think it should be TU,  even though it is only triggered when the upstream is unordered. The intent is, when triggered, that our concurrent collectors should be used with a forEach-like mechanism by which the collector concurrently receives elements in a temporal order.
 
Paul.


> Note that collectors individually get to choose whether they are TA or TU.  Choices we make for our canned collectors need not affect user-written collectors.  The model can handle both and users can predict the behavior of both.