RFR: 8079136: Accessing a nested sublist leads to StackOverflowError (original) (raw)

Ivan Gerasimov ivan.gerasimov at oracle.com
Wed May 6 14:17:51 UTC 2015

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 integers = new LinkedList<>(); integers.addAll(Arrays.asList(0, 1)); List 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 structurally modified 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

More information about the core-libs-dev mailing list