On 6 Feb 2016, at 14:29, Tagir F. Valeev <amaembo@gmail.com> 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.