stream() / parallelStream() methods

Kevin Bourrillion kevinb at
Fri Feb 8 15:28:46 PST 2013

Here's the other issue this raises.

To my knowledge there's no Streamable<T> interface defined.  Maybe it
wasn't needed; I'm not sure.  But once Iterable looks like this, now
Iterable becomes the new Streamable.  If you support a stream(), you'll
implement Iterable to expose that fact.  This is a little bit weird.  I'm
undecided on how big a problem it would be, but overall, Streamable<T>
seems like a pretty normal thing to have.

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

> 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?

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

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