stream() / parallel()

[Brian Goetz]

> The main issue is that you force all API developpers that want to
> implement a non parallel stream to have a good answer when user will
> call parallel().

That's not right.

Currently, the default implementation for parallel() is "stream()". 
Under the proposed change, the situation would be the same either way -- 
if the developer is willing to provide a good spliterator 
implementation, then it works well either seq or parallel, and if they 
are not, then they risk getting a weak parallel implementation.  So it 
doesn't change the balance of what the developer has to do, or what the 
downside is if they do a weak job.

> Given that not all sequential stream can be parallelized, what is the
> semantics of Stream.parallel().

Any stream can be parallelized; it just might not be a win to do so. 
Here's a stupid split on an arbitrary iterator: (first, rest).  A 
slightly less stupid split is (first n, rest), where n starts at 1 (so 
there's something to fork immediately) and doubles until it hits some 
threshold (so as the pool fills up, task management overhead is reduced.)