On 27 Jul 2015, at 20:53, Martin Buchholz <marti...@google.com> wrote: > > > 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.
I just implicitly assumed that was always the case :-) as i assume did many core library implementors. > > 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. Since there already exists an implicit policy governed by like 99.9% of the existing behaviour i do not see the need to be explicit about that policy for this particular issue, so i suggest we split into two. Paul.
