JDK 9 RFR(xs): 8177653: clarify restrictions on Iterator.forEachRemaining

[Martin Buchholz]

Looks good!

On Fri, Mar 31, 2017 at 11:28 AM, Stuart Marks <stuart.marks at oracle.com>
wrote:

>
> Hi all,
>
> Please review this small change to the spec of Iterator.forEachRemaining.
> I claim this change is non-normative, since the text to be added "other
> mutator methods of Iterator subtypes" is already covered by existing text
> "modifies the collection in any way". However, this bug arose because the
> originator of this bug report was calling ListIterator.add() within
> forEachRemaining, and expecting specific behavior, so I felt some
> amplification was warranted.
>
> Thanks,
>
> s'marks
>
>
> # HG changeset patch
> # User smarks
> # Date 1490984679 25200
> #      Fri Mar 31 11:24:39 2017 -0700
> # Node ID 7f316f93f2bd46a9a554c760034c1c25a18d3e05
> # Parent  a1d25a8fdc9855e59260345c32a5e7ad64051a4e
> 8177653: clarify restrictions on Iterator.forEachRemaining
> Reviewed-by: XXX
>
> diff -r a1d25a8fdc98 -r 7f316f93f2bd src/java.base/share/classes/ja
> va/util/Iterator.java
> --- a/src/java.base/share/classes/java/util/Iterator.java       Thu Mar
> 30 11:26:31 2017 -0700
> +++ b/src/java.base/share/classes/java/util/Iterator.java       Fri Mar
> 31 11:24:39 2017 -0700
> @@ -109,7 +109,8 @@
>       * Exceptions thrown by the action are relayed to the caller.
>       * <p>
>       * The behavior of an iterator is unspecified if the action modifies
> the
> -     * collection in any way (even by calling the {@link #remove remove}
> method),
> +     * collection in any way (even by calling the {@link #remove remove}
> method
> +     * or other mutator methods of {@code Iterator} subtypes),
>       * unless an overriding class has specified a concurrent modification
> policy.
>       * <p>
>       * Subsequent behavior of an iterator is unspecified if the action
> throws an
>