RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

Martin Buchholz martinrb at google.com
Mon Nov 21 20:32:29 UTC 2016


Thanks.  Seems like progress.

The spec below seems like it could be improved, but not sure how...

+     * <p>
+     * The behavior of an iterator is unspecified if the action performs
the
+     * following side-effects:
+     * <ul>
+     * <li>modifies the underlying collection; or
+     * <li>calls the {@link #remove remove} method.
+     * </ul>
+     * <p>
+     * Subsequent behavior of an iterator is unspecified if the action
throws an
+     * exception.


Maybe """The behavior of an iterator is unspecified if an action modifies
the collection in any way (even by calling the {@link #remove remove}
method)."""

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."""

The default implementation cannot ensure desirable properties we might
easily implement for a concrete implementation, e.g. whether the iterator
is exhausted after a call to forEachRemaining where an action threw.

Should we be aligning Iterator and Spliterator, which have similar
questions?


More information about the core-libs-dev mailing list