stream() / parallelStream() methods

[Joe Bowbeer]

I'm OK with parallelStream(). It did raise a question when I used it for
the first time, but it was also easy to find in the IDE. I wanted
"parallel" and knew what I was getting into; as opposed to someone splicing
a parallel() into their expression as an afterthought..

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?
 On 02/09/13 11:41, Brian Goetz wrote:

 You can't drop a bomb like that and walk away!  You have to explain why you
> don't like it, because I suspect most people's first guess about why will
> be wrong.
>
> I'll take my best stab at explaining why:
>

Yes, thanks. Stateful Stream methods are clearly problematic.
Most people like them anyway because they are convenient.
And in any case, whenever they show up, many API discussions follow.


  because it (like the stateful methods
> (sort, distinct, limit)) which you also don't like, move us incrementally
> farther from being able to express stream pipelines in terms of traditional
> data-parallel constructs, which further constrains our ability to to map
> them
> directly to tomorrow's computing substrate, whether that be vector
> processors,
> FPGAs, GPUs, or whatever we cook up.
>
> Filter-map-reduce map very cleanly to all sorts of parallel computing
> substrates; filter-parallel-map-**sequential-sorted-limit-**
> parallel-map-uniq-reduce
> does not.
>
> So the whole API design here embodies many tensions between making it easy
> to
> express things the user is likely to want to express, and doing is in a
> manner
> that we can predictably make fast with transparent cost models.
>
>