RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit

[Paul Sandoz]

On May 3, 2013, at 9:42 PM, Peter Levart <peter.levart at gmail.com> wrote:

> 
> On 05/03/2013 09:10 PM, Paul Sandoz wrote:
>> Hi Peter,
>> 
>> On May 3, 2013, at 12:07 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>>> Hi Paul,
>>> 
>>> Maybe the JavaDoc could also suggest that the trySplit producing N+0 result should converge so that returned Spliterator eventualy produces either null+N or n+m (n<N, m<N) and splitting terminates in finite number of steps. Also I don't know why would any Spliterator implementation want to return 0+N from trySplit (the N+0 return can be useful because the returned instance can be of different class/implementation, but the 0+N has no utility), so the javaDoc could be more strict:
>>> 
>> 
>> N could be 0, which can occur for spliterators of maps, but for N > 0 i think it unlikely.
>> 
>> However, i am not sure we should explicitly rule it out given sizes may be estimates. I think it may be prudent to give spliterators the wiggle room, as some wiggle in unexpected ways, and document what the best way to wiggle is.
>> 
>> How about we add some non-normative text to the api note of trySplit? i can log another issue for that.
> 
> Now looking at the whole JavaDoc, I see there is already the following at the top of trySplit:
> 
>      * <p>Unless this Spliterator covers an infinite number of elements,
>      * repeated calls to {@code trySplit()} must eventually return {@code null}.
> 
> Which I think is enough of a hint for the eventual implementor of the interface to conclude that this (and not N+0 or 0+N) is the sole terminating condition for the process of splitting.

Right, that is the key piece of information for termination. Practically speaking such termination is unlikely to be encountered by the stream implementation since splitting is controlled by a size threshold. 

However, we do test that null is eventually returned, within the bounds of a certain depth (2^18, which is more than enough to detect a bad spliterator given the size of the input data).

Paul.