iterator()/spliterator() and stateful operations

[Paul Sandoz]

Note that sorted() is problematic for both sequential and parallel pipelines:

  Stream.generate(() -> "A").limit(WITH_REALLY_LARGE_VALUE).sorted().iterator().next();

since it is a barrier in both cases.


On May 20, 2013, at 5:34 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
> So, questions:
> - Should we go ahead with the proposed changes above for generators (make them unsized)

Yes. 

In a previous email on Stream.generate we had the choice of SIZED of Long.MAX_VALUE or infinite. I think infinite makes more sense and it allows us to produce an infinite, unordered and IMMUTABLE stream of generated values (verified in patch) thereby working better in conjunction with distinct and substream/limit.


> and iterator (make it sequential)?

Yes.


> - Should we go further, trimming the behavior of spliterator() to reduce time/space consumption, or are we OK here given its likely narrower usage profile?


I am inclined not to interfere with it too much and trying to make it "magical" in avoiding some but not all edge cases.

One workaround is for the developer to place a sequential() before spliterator(), which is also the implementation solution for iterator:

    @Override
    public final Iterator<P_OUT> iterator() {
        return Spliterators.iteratorFromSpliterator(sequential().spliterator());
    }

Paul.