RFR: 8079136: Accessing a nested sublist leads to StackOverflowError
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<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
>
>
>
More information about the core-libs-dev
mailing list