stream() / parallelStream() methods

Brian Goetz brian.goetz at
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.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