RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

[Martin Buchholz]

On Mon, Nov 21, 2016 at 2:29 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> A linked list based implementation could report hasNext() == false when
> currentNode.next == null, but that might change before the next call to
> hasNext().  AFAIK, all of our concrete implementations don't have this
> property - the iterator being exhausted is a "sticky" property, in part
> because it's nice to the GC to null out fields at the end.  One can imagine
> an iterator (or spliterator) designed to work differently, e.g. tryAdvance
> would be a way of "polling" the stream of elements to see whether any are
> available, and would eventually visit all elements added.
>
>
> Back in the real world, forEachRemaining is a particularly strong hint
> that this iterator/spliterator should be forever exhausted.
>
>
> Yes :-) i would argue as strong a hint as that of hasNext returning false.
>
>
Stronger, perhaps!  There's a corner case where a user sees hasNext()
returning false, then calls remove().  Perhaps it's a weird way of deleting
the last element. That seems more defensible user code than calling
remove() after forEachRemaining.  In some classes maintaining the ability
to delete the last element is a burden, as in ArrayBlockingQueue.


> Paul.
>
> Perhaps where that matters (ArrayBlockingQueue) we could even add such a
> thing to the spec.  We discourage use of Iterators with ABQ, in part
> because in the past there was no way to "close" an Iterator.  But now there
> is!
>
>
>