Setting of UNORDERED on concurrent collectors

[Brian Goetz]

> I'm using the forms of collect that hide the collections completely
> (except as a return type).  I was only thinking about the order vs
> unorder and parallel vs sequential aspects -- and I'd prefer to keep it
> that way.  So, for example:
>
> collect(unordered+parallel) should perform a concurrent collection?

Most of the collectors hide the return type, but expose the 
concurrent-ness of the return type in their name.

Earlier, we had a separate bag (ConcurrentCollectors) for concurrent 
collectors.  I disliked this because, with the obvious static imports, 
the user couldn't tell whether

   parStream.collect(groupingBy(f))

would be a concurrent (unordered) reduction or a traditional (ordered) 
one.

> (But you've already indicated that yes I do, in addition, need to think
> about the collection type in this case even if I don't handle the
> construction, right?)

Not the specific collection type.  You do need to reason about shape 
(List vs Map), and you need to reason about concurrent vs not (HashMap 
vs CHM), but not necessarily about List vs Set.

> Whereas your question is:
>
> collectConcurrent(ordered+parallel) should disregard order?

More whether:

   Collectors.groupingByConcurrent(f)

should declare itself to be an unordered Collector, just as toSet() is.