Stream, spliterator, supplier and size (original) (raw)

Brian Goetz brian.goetz at oracle.com
Fri Dec 14 07:37:57 PST 2012

By the way, it used to work as you suggest. Writing spliterators for collections like ArrayList was very painful, because you still had to check that the collection hadn't been modified since the spliterator was captured (otherwise you might be iterating the wrong array.) Which meant that you had to write a proxy spliterator which did checks the first time iterator() / split() / forEach() were called, before passing control onto the array spliterator. This was messy. Now, we just pass

() -> Arrays.spliterator(array, 0, size)

to stream() and we're done!

So the alternative formulation is actually much worse for anyone who wants to make a Stream if they are wrapping it around a mutable collection.

Also we have stream(Spliterator) sitting right next to it so if you are ready to bind immediately, you can.

On 12/14/2012 9:39 AM, Remi Forax wrote:

Brian explains why there is methods in Streams that takes a Supplier and the flags in a previous mail (I'm too lazy to find it now). Stream stream(Supplier<Spliterator> supplier, int flags)

I've trouble to understand why we need to expose two semantics to our poor users, I think it's better to decide whenever (1) the spliterator is created when collection.stream() is called or (2) the spliterator is created when a terminal operation like stream.forEach is called. It has severe implications on the way the pipeline works under the hood because the pipeline ops may relies on the size of the collection which may be different if the collection is mutated between the creation of the stream and the call to the terminal operation. cheers, Rémi

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