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