stream() / parallelStream() methods

[Brian Goetz]

> The separation of parallel() from stream() also presents more
> possibilities for the user, and therefore also raises questions. Where
> in the expression does parallel() belong? In the parallel string-compare
> example, I had a choice between boxed().parallel() or
> parallel().boxed(). Which is "right"? Or maybe I should insert
> parallel() even later in the expression?

Good question.  Clearly more education will be needed here.

There's two axes on which to evaluate how to use .parallel() and 
.sequential(); semantic and performance.

The semantics are straightforward.  If a stream starts out sequential, then:

   foo.filter(...).parallel().map(...)

will do the filtering sequentially and the mapping in parallel.  Whereas

   foo.parallel().filter(...).map(...)

will do both in parallel.  I think users can understand that aspect of 
it; it seems pretty straightforward.

If the stream is already s/p then s()/p() are no-ops (well, a single 
virtual call and a field read.)

On the performance front, that's always a moving target, but currently 
.parallel() on a "naked" (no ops added yet, as in the second case) 
stream is much cheaper than .parallel() on a stream that already has ops 
(like in the first case.)