RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Doug Lea dl at cs.oswego.edu
Sat May 9 11:15:10 UTC 2015

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.


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),

... which can define methods relying on the specified full cascade.

(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.)


More information about the core-libs-dev mailing list