On Mon, Jul 27, 2015 at 1:19 AM, Paul Sandoz <paul.san...@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#modCount 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.
