stream() / parallelStream() methods
kevinb at google.com
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 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
> 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