brian.goetz at oracle.com
Sat Apr 20 14:47:49 PDT 2013
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
More information about the lambda-libs-spec-observers