parallelStream() methods (original) (raw)

Brian Goetz brian.goetz at oracle.com
Fri Feb 8 14:30:14 PST 2013

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

 default Stream<E> stream() {
     return Streams.stream(() -> Streams.spliterator(iterator(),

size(), Spliterator.SIZED), Spliterator.SIZED); }

 default Stream<E> 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?

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