On Mon, Nov 21, 2016 at 2:29 PM, Paul Sandoz <paul.san...@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! > > >
