> On 21 Nov 2016, at 13:21, Martin Buchholz <marti...@google.com> wrote: > > > > On Mon, Nov 21, 2016 at 1:01 PM, Paul Sandoz <paul.san...@oracle.com > <mailto:paul.san...@oracle.com>> wrote: > > > There's the question of what to promise after a call to forEachRemaining > > (whether or not an action threw). Perhaps a blanket > > """Subsequent behavior of an iterator is unspecified after a call to this > > method.""" > > > > I think that is overly limiting, it’s exceptions and remove that are > problematic. Assuming no exception it is fine to subsequently call next, > hasNext and forEachRemaining, each has well defined behaviour (throws > NoSuchElementException, false, no-op respectively). > > In a concurrent world, it's not so clear.
Good point, yes, i was thinking non-concurrent, but i would still expect it to hold for weakly consistent iterators. > 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. 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!
