Kevin Bourrillion kevinb at
Thu Feb 21 08:06:52 PST 2013

1. Yes please.
2. And this time I won't hijack the thread.

On Thu, Feb 21, 2013 at 7:44 AM, Brian Goetz <brian.goetz at> wrote:

> Currently we define stream() and parallelStream() on Collection, with
> defaults like:
>     default Stream<E> stream() {
>         return
>            () -> Streams.spliterator(iterator()**, size(),
>                                      Spliterator.SIZED),
>            Spliterator.SIZED);
>     }
> In other words, if a Collection does not override stream(), it gets the
> stream based on the iterator.
> It has been suggested that we could move stream/parallelStream() up to
> Iterable.  They could use an almost identical default, except that they
> don't know the SIZED flag.  (The default in Collection would stay, so
> existing inheritors of the Collection default wouldn't see any difference.
>  (This is why default methods are virtual.))
> Several people have asked why not move these to Iterable, since some APIs
> return "Iterable" as a least-common-denominator aggregate type, and this
> would allow those APIs to participate in the stream fun.  There are also a
> handful of other types that implement Iterable, such as Path
> (Iterable<Path>) and DirectoryStream (where we'd added an entries() method,
> but that would just then become stream()).
> The sole downside is that it creates (yet another) external dependency
> from java.lang.Iterable -- now to
> Thoughts?

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

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