RFR: JDK-8114832 it.next on ArrayList throws wrong type of Exception after remove(-1)

Martin Buchholz martinrb at google.com
Mon Jul 27 18:53:01 UTC 2015

On Mon, Jul 27, 2015 at 1:19 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> My guiding principle here was that argument validation should not result
> in side-effects. Thus the state of a collection should remain unchanged if
> an exception is thrown due to an invalid argument of an operation.
That is indeed a good principle.  All or nothing!

But in the case of modCount, one might consider it to record both actual
and attempted modifications.
I would be OK if we decided to make this consistent across all JDK
implementations.  Currently we don't have any internal policy on this,
although you can read the spec
as requiring successful, not attempted modifications.

> ArrayList.remove is inconsistent with regards to nearly all the other
> ArrayList methods, add(int, E) and addAll(int, Collection) for an out of
> bounds index, and addAll(Collection ), removeAll, retainAll, removeIf,
> replaceAll and sort for a null argument. It’s not inconsistent with
> ArrayList.removeRange, except for if an invalid range from > t, but is
> inconsistent with AbstractList.removeRange. It’s also inconsistent
> LinkedList and CopyOnWriteArrayList *and* sub-lists of ArrayList and
> AbstractList. And inconsistent more generally for other Collection
> implementations, such as Queue.add/offer/remove implementations that do not
> accept null values.
> The behaviour of ArrayList.remove, and also ArrayList.removeRange, are
> outliers [*]. It’s also a rather obscure difference behaviour with likely
> minimal impact if changed (far less so than the change to Arrays.toList) .

I agree that if we make a policy decision here, we can change it and the
compatibility impact is minimal.

More information about the core-libs-dev mailing list