RFR: 8079136: Accessing a nested sublist leads to StackOverflowError (original) (raw)
Ivan Gerasimov ivan.gerasimov at oracle.com
Sat May 9 14:36:30 UTC 2015
- Previous message: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError
- Next message: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 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 prove.
I've just checked the last webrev at http://cr.openjdk.java.net/~igerasim/8079136/03/webrev/ 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, Ivan
(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
- Previous message: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError
- Next message: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]