Drop Arrays.parallelStream()?

[Brian Goetz]

For what its worth, the internal tracking title of this project is "Bulk 
data-parallel operations on Collections."  I'm not willing to relegate 
such central functionality to something that is tucked into a remote 
corner of the API -- it was *already* a huge (but warranted) 
discoverability compromise to have the stream/parallelStream "bun" 
methods in the first place!  Two buns for this case -- which will be 
probably 90% of stream constructions -- would be too much.  So, I cannot 
see my way to removing Collection.parallelStream.  However, I am willing 
to ditch the parallel versions of the static stream factory methods, 
largely on the basis that the Collection versions will be used 100x as 
much as any one of the static factories.

The "inconsistency" of this position doesn't bother me one tiny bit; it 
is a pragmatic compromise.  (In fact, I'm not even sure its an 
inconsistency at all, since they're kind of different beasts -- one is a 
static factory, the other is a view onto an existing data structure.)

So I'm willing to meet you 95% of the way there.


On 4/20/2013 6:16 PM, Joe Bowbeer wrote:
> I agree with Mike and Tim.  I'd remove all the parallelStream() methods
> now - and add some or all back later if they ARE needed.
>
> I don't like the inconsistency of having parallelStream available on
> some stream factories and not on others.
>
>
>
>
> On Sat, Apr 20, 2013 at 3:10 PM, Tim Peierls <tim at peierls.net
> <mailto:tim at peierls.net>> wrote:
>
>     On Sat, Apr 20, 2013 at 6:01 PM, Mike Duigou <mike.duigou at oracle.com
>     <mailto:mike.duigou at oracle.com>> wrote:
>
>         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.
>
>
>     Agreed.
>
>     I see the discoverability of Collection.parallelStream() as a
>     potential pedagogical drawback. "Do I use parallelStream() or
>     stream().parallel()?"
>
>     For most folks, the expectation and intuition will be sequential, so
>     take advantage of that: Let people come to c.stream().parallel()
>     slowly and deliberately, after getting their feet wet with c.stream().
>
>     --tim
>
>