RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove (original) (raw)

Martin Buchholz martinrb at google.com
Mon Nov 21 23🔞11 UTC 2016

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!

More information about the core-libs-dev mailing list