parallelStream() methods (original) (raw)

Kevin Bourrillion kevinb at google.com
Fri Feb 8 15:23:10 PST 2013

• Previous message: stream() / parallelStream() methods
• Next message: stream() / parallelStream() methods
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Can we make our best attempt to specify Iterable.stream() better than Iterable.iterator() was?

I haven't worked out how to say this yet, but the idea is:

• If at all possible to ensure that each call to stream() returns an actual working and independent stream, you really really should do that.
• If that's just not possible, the second call to stream() really really should throw ISE.

(Yes, I do realize most Iterables by far will just inherit stream(), so it will only be as repeat-usable as iterator() is.)

On Fri, Feb 8, 2013 at 3:20 PM, Kevin Bourrillion <kevinb at google.com> wrote:

Yeah, I think we have little choice but to do this. It makes sense, and without it, Guava will just end up having to offer a static helper method to return (iterable instanceof Collection) ? ((Collection) iterable).stream() : Streams.stream(Streams.spliteratorUnknownSize(iterable.iterator()), 0). Blech.

(Tangentially, I would really love to drop parallelStream() and let people call stream().parallel(). But I haven't managed to scour the archives to find if that argument's already suitably played out.)

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

-- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com

• Previous message: stream() / parallelStream() methods
• Next message: stream() / parallelStream() methods
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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