Drop Arrays.parallelStream()?

[Brian Goetz]

> Brian, What do you mean by the following?
>
>     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 [...] would be too much.
>
> Are you referring to the fact the there is no ParallelStream type?

No, that's a big plus -- one Stream to rule them all!

The negative was having to have the

   .stream()
and
   .parallelStream()

methods at all.  We originally really liked the idea of

   collection.filter(..)...
             ^ no view method!

but for various reasons reluctantly concluded it was untenable.  But 
that still doesn't mean we like having the new functionality be so far 
removed from Collection.  And if one layer removed is suboptimal, two is 
worse.

> Note that the common point that Mike, Tim, and I raised is consistency.
>   Your proposal to remove methods is creating the inconsistency, so I

Not really.  We were already inconsistent; they were present for 
Collection and for Array factories but not for range factories, 
generator factories, etc.  You could argue the new proposed state is 
more consistent (all the view methods have a parallel counterpart; all 
the static factories don't) but that's not what I consider its primary 
benefit.

> don't understand the comment that you're meeting us 95% of the way there...

Removing all but one of the parallelStream methods.

> Still, why, if you're so interested in advertising the parallel
> features, do you *want* to remove these methods from Arrays?

Simply: return on API surface area.  The return for having it the one 
extra method on Collection is large; the return for having 100 extra 
methods for 100 infrequently-used factory methods is small (even in the 
aggregate).  Arrays.parallelStream() was eight more methods -- four 
types x two forms.  (Others here have argued that "too many forms of the 
same method is a smell"; also there have been plenty of calls for a 
round of YAGNIism.)

>     but I don't particularly like the idea of encouraging people to
>     think this is a sequential library with some parallel bags nailed on
>     the side
>
> Then again, users like consistency...

I'm not saying consistency is unimportant.  But in my experience, 
"consistency" can be used to justify nearly any position -- one can 
always find a precedent in a complex system to be "consistent" with.  So 
I want more than mere consistency.  (Not to mention many consistencies 
are of the "foolish hobgoblin" variety.)