> On 6 Feb 2016, at 14:29, Tagir F. Valeev <[email protected]> wrote: > > Hello! > > PS> I still disagree and pushing back on the support for splitting > PS> after partial traversal. It’s not a pattern i think we should > PS> encourage and propagate so such behaviour can be generally relied > PS> upon, and predominantly for edge cases. That’s where the > PS> complexity string is being pulled on. While your fix in isolation > PS> is not terribly complex, it is more complex than the alternative > PS> (which was actually the intent of the current impl, we just forget to > include the check). > > I still don't like doing this, but as Brian agreed with you [1], seems > I have no other choice.
Thanks for accommodating. > Here's updated webrev: > http://cr.openjdk.java.net/~tvaleev/webrev/8148838/r3/ > 188 public Spliterator<P_OUT> trySplit() { 189 if (isParallel && !finished) { 190 init(); 191 192 if (buffer != null && buffer.count() > 0) // partial traversal started 193 return null; Why don’t you check if "buffer == null” at #189? i.e. similar to forEachRemaining: @Override public void forEachRemaining(Consumer<? super P_OUT> consumer) { if (buffer == null && !finished) { For clarity and consistency we should key off the "buffer == null” partial traversal guard. The state of "buffer != null" and “buffer.count() == 0” will be when traversal has completed i.e. "finished == true" (see fillBuffer). Paul.
