Iterable.stream()

Brian Goetz brian.goetz at oracle.com
Thu Feb 21 07:44:24 PST 2013


Currently we define stream() and parallelStream() on Collection, with 
defaults like:

     default Stream<E> stream() {
         return Streams.stream(
            () -> 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 java.util.stream.

Thoughts?



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