Drop Arrays.parallelStream()?

[Mike Duigou]

On Apr 20 2013, at 14:47 , Brian Goetz wrote:

> We dropped the parallel versions of all the static generator/factory methods in Streams a while ago, in favor of just letting people do (say) IntStream.range(...).parallel().  Since then, we have also greatly reduce the runtime cost of Stream.parallel().
> 
> We still have the separate .parallelStream() method on Collection and in the static methods in Arrays.
> 
> I still really like Collection.parallelStream; it has huge discoverability advantages, and offers a pretty big return on API surface area -- one more method, but provides value in a lot of places, since Collection will be a really common case of a stream source.
> 
> Arrays are in a middle ground.  We have eight Arrays.stream() methods and eight Arrays.parallelStream() methods (four types, both whole-array and slice versions).  I'm having a bit of a YAGNI twinge for the Arrays.parallelStream forms, and could see ditching them.  (The implementations are trivial and small, so that is not an argument to ditch them -- we should make this decision purely on API considerations.)
> 
> If we did this, Collection would have the sole parallelStream method; everything else would have to go through .parallel().  Which seems fine to me.
> 

I would probably always use always .stream().parallel() idiomatically for consistency unless parallelStream() told me why I should use it instead. I say toss all of the parallelStream() methods unless there's an impl efficiency dependent reason to retain some of them.

Mike