stream() / parallelStream() methods

Kevin Bourrillion kevinb at
Fri Feb 8 15:47:46 PST 2013

Sure, sure: it's much more about perception than specific impediment to

On Fri, Feb 8, 2013 at 3:44 PM, Brian Goetz <brian.goetz at> wrote:

> If I fail in my bid to kill parallelStream() then could we at least keep
>> it on Collection?  With Iterable already growing from 1 to 3 methods,
>> that one extra is pretty significant bulk.  (Still, let's kill it
>> entirely :-))
> I'm not sure I get this "bulking" argument.
> The implementation on Iterable will be a default.
> Let's say you're implementing an Iterable.  There are two ends of the
> spectrum:
> 1.  You are building a high-performance data structure.  You are
> definitely going to want to create your own spliterators and offer the best
> parallel performance.  So you are happy to see parallelStream().
> 2.  You are wrapping some other aggregates that you just want to be
> Iterable, so you cobble together an Iterator from whatever you've got. In
> which case you're likely to take the default stream/parallelStream
> implementations.  So you don't care that Iterable has parallelStream.
> So at the ends, either you like it, or you're agnostic.  What's in the
> middle that's different?  I'm not seeing it.

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

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