unordered() (original) (raw)

Brian Goetz brian.goetz at oracle.com
Fri Dec 21 14:13:54 PST 2012

So, the move to a more explicit choice of merging or concurrent tabulation also reduces (heh) the need for unordered(), though it does not eliminate it completely. (Limit, cancelation, and duplicate removal all have optimized versions if encounter order is not significant.)

Kevin pointed out that .unordered() is pretty easy to miss, and people will not know that they don't know about it. One possible is to make it more explicit at one end of the pipeline or the other (the only operation that is order-injecting is sorted(), and presumably if you are sorting you really care about encounter order for the downstream ops, otherwise the sort was a waste of time.)

The proposed tabulator / reducer stuff makes the order-sensitivity clear at the tail end, which is a good place to put it -- the user should know whether a reduce or a forEach is what they want -- if not the user, who? (Only the user knows whether he cares about order or not, and knows whether his combination functions are commutative or not.) The other less-ignorable place to put an ordering opt-out is at the head; we could make things more clear with adding

.parallelUnorderedStream() alongside .stream() and .parallelStream()

The obvious implementation of parallelUnorderdStream is:

 default Stream<E> parallelStream() {
     return stream().unordered();
 }

which is also the most efficient place to put the .unordered (at the head.)

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