Hi Pavel!
It was intentional to avoid checking for co-modification for every pair
of list-sublist in the chain.
It's surely enough to only compare modCount of the root and the sublist
we're dealing with.
However, I didn't notice that SubList.size() had not checked for
comodifications recursively on its parent.
And I agree with you that it's done better now, when modifications of
the root list are caught faster.
Thanks for noticing it!
Sincerely yours,
Ivan
I noticed that it's not necessary to check the difference in modCount in
every subList and its immediate parent pair,
On 06.05.2015 12:12, Pavel Rappo wrote:
Ivan,
It looks like your change (I don't know whether it was intentional or not)
brings some more "fail-fast"-ness which is good! For instance, before the
change, this snippet:
List<Integer> integers = new LinkedList<>();
integers.addAll(Arrays.asList(0, 1));
List<Integer> sublist = integers.subList(0, 2).subList(0, 2);
System.out.print(sublist.size());
integers.clear();
System.out.print(" " + sublist.size());
would shamelessly produce: 2 2. But now it throws CME. Which is more expected I
believe. The reason is that now `checkForComodification` consults topmost list
rather than an immediate parent. Well to AbstractList's credit it's not a bug as
it falls into the category described in javadoc of java.util.List.subList:
* The semantics of the list returned by this method become undefined if
* the backing list (i.e., this list) is <i>structurally modified</i> in
* any way other than via the returned list. (Structural modifications are
* those that change the size of this list, or otherwise perturb it in such
* a fashion that iterations in progress may yield incorrect results.)
But still, it's a nice bonus for safety.
-Pavel
