parallelStream() methods (original) (raw)

Kevin Bourrillion kevinb at google.com
Fri Feb 8 15:20:44 PST 2013

Yeah, I think we have little choice but to do this. It makes sense, and without it, Guava will just end up having to offer a static helper method to return (iterable instanceof Collection) ? ((Collection) iterable).stream() : Streams.stream(Streams.spliteratorUnknownSize(iterable.iterator()), 0). Blech.

(Tangentially, I would really love to drop parallelStream() and let people call stream().parallel(). But I haven't managed to scour the archives to find if that argument's already suitably played out.)

On Fri, Feb 8, 2013 at 2:30 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

Currently, we define stream() and parallelStream() on Collection, with default of:

default Stream stream() { return Streams.stream(() -> Streams.spliterator(iterator()**, size(), Spliterator.SIZED), Spliterator.SIZED); } default Stream parallelStream() { return stream().parallel(); } So the default behavior is "get an Iterator, turn it into a Spliterator, and turn that into a Stream." Then the specific Collection classes generally override it, providing better Spliterator implementations and more precise flag sets.

Several people have requested moving stream/parallelStream up to Iterable, on the theory that (a) the default implementations that would live there are not terrible (only difference between that and Collection default is Iterable doesn't know size()), (b) Collection could still override with the size-injecting version, and (c) a lot of APIs are designed to return Iterable as the "least common denominator" aggregate, and being able to stream them would be useful. I don't see any problem with moving these methods up to Iterable. Any objections?

-- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com

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