stream() / parallelStream() methods
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-experts
mailing list