stream() / parallelStream() methods

[Brian Goetz]

> Here's another breach in my promise not to have an opinion
> about anything in the Steam API: I think "parallelStream()"
> is much nicer than "stream().parallel()".

I do too, but I also recognize that is mostly just taste and we could 
get used to either.  But, let's turn the question around, because we 
have an inconsistent API right now with respect to stream constructors, 
and we should decide whether we want to choose that deliberately (which 
I think is fine), or go one way or the other.

We have a number of factories in Streams like:

   Streams.intRange(from, to)
   Streams.generate(T, UnaryOperator<T>)

We do *not* have explicit parallel versions of each of these; we did 
originally, and to prune down the API surface area, we cut them on the 
theory that dropping 20+ methods from the API was worth the tradeoff of 
the surface yuckiness and performance cost of .intRange(...).parallel(). 
  But we did not make that choice with Collection.

We could either remove the Collection.parallelStream(), or we could add 
the parallel versions of all the generators, or we could do nothing and 
leave it as is.  I think all are justifiable on API design grounds.

I kind of like the status quo, despite its inconsistency.  Instead of 
having 2N stream construction methods, we have N+1 -- but that extra 1 
covers a huge number of cases, because it is inherited by every 
Collection.  So I can justify to myself why having that extra 1 method 
is worth it, and why accepting the inconsistency of going no further is 
acceptable.

Do others disagree?  Is N+1 the practical choice here?  Or should we go 
for the purity of N?  Or the convenience and consistency of 2N?  Or is 
there some even better N+3, for some other specially chosen cases we 
want to give special support to?