RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Ivan Gerasimov ivan.gerasimov at oracle.com
Sat May 9 14:36:30 UTC 2015

On 09.05.2015 14:15, Doug Lea wrote:
> On 05/08/2015 02:17 PM, Ivan Gerasimov wrote:
>>> The spec says "The returned list is backed by this list"
>>> and "The subclass's set(int, E), get(int), add(int, E), remove(int),
>>> addAll(int, Collection) and removeRange(int, int) methods all 
>>> delegate to the
>>> corresponding methods on the backing abstract list".
>>> It is possible that no differences could be detected, but it would take
>>> some effort to prove.
>> Hm.  Let me try.
>> We have two options:
>> 1) Sublist of an arbitrary AbstractList, which is not SubList itself.
>> 2) Sublist of another SubList.
> Plus:
> 3) An arbitrary wrapping of SubList, as seen for example in Collections
> utilities like synchronizedList:
>         public List<E> subList(int fromIndex, int toIndex) {
>             synchronized (mutex) {
>                 return new SynchronizedList<>(list.subList(fromIndex, 
> toIndex),
>                                             mutex);
>             }
>         }
> ... which can define methods relying on the specified full cascade.
Sorry, I cannot see how wrapping of SubList is different from any other 
dealing with the sublist's API.
Shouldn't it remain as before, as long as we preserve the list's behavior?

The consistency of the behavior of the sublist was what I was trying to 

I've just checked the last webrev at 
and I could find only a few minor behavioral differences:
- SubList.size() checks for co-modifications more severely (it could 
easily be restored, but I agree with Pavel that now it's done better);
- validity of the index is only checked the for the inner-most sublist 
(it's surely enough, since the sublist is fully enclosed into its parent);
- when updating size and modCount, the sublist chain is traversed in the 
loop and not recursively (not really a behavioral change, as it hardly 
be noticed from outside).

Another argument, supporting the proposed fix for AbstractList.SubList 
is that it is very similar to what was implemented in ArrayList.SubList.
If the later was conforming to the spec, why are there doubts that the 
new version AbstractList.SubList break it?

Sincerely yours,

> (I'm not trying to be hostile about this; just trying to avoid the
> usual problems seen when trying to change many Java 1.0-1.2 era
> classes that over-specified behavior. Luckily, people
> have learned since then not to do this so much.)
> -Doug

More information about the core-libs-dev mailing list