stream() / parallelStream() methods

Brian Goetz brian.goetz at
Sat Feb 9 10:48:49 PST 2013

> 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:


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


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.)

More information about the lambda-libs-spec-observers mailing list