On May 3, 2013, at 9:42 PM, Peter Levart <[email protected]> wrote:
> > On 05/03/2013 09:10 PM, Paul Sandoz wrote: >> Hi Peter, >> >> On May 3, 2013, at 12:07 PM, Peter Levart <[email protected]> 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.
