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

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.

Plus:

  1. An arbitrary wrapping of SubList, as seen for example in Collections utilities like synchronizedList: public List 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.

(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