On Mon, Jul 27, 2015 at 1:19 AM, Paul Sandoz <paul.sandoz@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 https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#modCou... 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.