No-reuse streams

Brian Goetz brian.goetz at oracle.com
Mon Nov 19 08:25:45 PST 2012


BTW, I know you've used the trick of asking for an iterator() to for 
"pull mode" for performance testing purposes.  We've got a new trick for 
forcing that in our tests; see the use of PullOnlyOp in the latest test 
sources.

Returning the same iterator/spliterator is a possibility, and not 
entirely precluded by this approach, though it would require special 
support.  (This approach is what is used by 
Socket.get{Input,Output}Stream.)  The current behavior, which I would 
guess is dispensing a new iterator that will throw when you try and use 
it, is not so great.

On 11/19/2012 11:19 AM, Aleksey Shipilev wrote:
> Well, of course!
>
> I was thinking about returning the same iterator nevertheless; so that
> we share the traversal states between two iterators from iterator()
> call. I think this provisioning would help to write cleaner code in some
> of the cases, at the cost of making stream appear to bear the state. I'm
> fine with opting out of that behavior if it is considered not that clean.
>
> -Aleksey.
>
> On 11/19/2012 07:50 PM, Brian Goetz wrote:
>> The iterator() method (and soon, spliterator()) are the escape hatch for
>> "the library can't help me, I have to do it myself."  You then get the
>> iterator and can do whatever you want with it.  But, what you can't do
>> is call iterator(), pull elements from the stream, and *then* try and do
>> more stream operations on that stream.
>>
>> On 11/19/2012 10:01 AM, Aleksey Shipilev wrote:
>>> On 11/19/2012 06:29 PM, Paul Sandoz wrote:
>>>> Brian and I just pushed a changeset that:
>>>>
>>>> - turns Stream/IntStream.iterator() into a terminal operation
>>>>
>>>> - only one terminal operation may be performed on at most one stream
>>>> in the pipeline, otherwise an ISE will be thrown.
>>>
>>> Isn't iterator() the exception from this rule, being the "extension" of
>>> the stream? I would naturally presume the *same* iterator is returned
>>> for the given stream, so this will still be the valid code:
>>>
>>>    Stream<T> stream = ...;
>>>    T first = stream.iterator().next()
>>>    // ...many, many lines of code...
>>>    T second = stream.iterator().next()
>>>
>>> -Aleksey.
>>>
>


More information about the lambda-dev mailing list