Setting of UNORDERED on concurrent collectors

Brian Goetz brian.goetz at
Mon Apr 8 12:08:49 PDT 2013

Now that we've removed collectUnordered in favor of a more general 
unordered() op, we should consider what should be the default behavior for:


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 

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.

More information about the lambda-libs-spec-experts mailing list