parallelStream() methods (original) (raw)

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

Here's the other issue this raises.

To my knowledge there's no Streamable 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 seems like a pretty normal thing to have.

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

Currently, we define stream() and parallelStream() on Collection, with default of:

default Stream stream() { return Streams.stream(() -> Streams.spliterator(iterator()**, size(), Spliterator.SIZED), Spliterator.SIZED); } default Stream 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 google.com

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