parallelStream() methods (original) (raw)

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

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

On Fri, Feb 8, 2013 at 3:44 PM, Brian Goetz <brian.goetz at oracle.com> 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 google.com

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