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
