I assigned this to Paul (hope that's OK)
JDK-8168745
Iterator.forEachRemaining vs. Iterator.remove
On Tue, Oct 25, 2016 at 4:13 PM, Paul Sandoz wrote:
>
> > On 25 Oct 2016, at 15:16, Martin Buchholz wrote:
> >
> > Actually, the ArrayList implementation updates fields only at the end of
> the i
> On 25 Oct 2016, at 15:16, Martin Buchholz wrote:
>
> Actually, the ArrayList implementation updates fields only at the end of the
> iteration, so if an action throws in the middle, the iterator is
> semi-corrupted (in the sense that remove() will remove the "wrong" element
> and next will r
Actually, the ArrayList implementation updates fields only at the end of
the iteration, so if an action throws in the middle, the iterator is
semi-corrupted (in the sense that remove() will remove the "wrong" element
and next will return previously visited elements). I think it's best to
say in th
Hi Martin,
Hmm…
The intent of ArrayList/Vector/LinkedList implementations is clear, leave the
iterator in the same state as a last successful next call.
I believe ArrayDeque’s iterator (in repo, unsure about your updates) has
different behaviour e.g.
ad.next();
ad.forEachRemaining(…);
a
It doesn't make a lot of sense for users to call Iterator.remove after
calling Iterator.forEachRemaining.
The default implementation has no choice but to do
while (hasNext())
action.accept(next());
upon which remove() removes the last element. What should overriding
implemen
