RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

[Doug Lea]

On 05/08/2015 10:49 AM, Ivan Gerasimov wrote:
>> I believe that they also break the AbstractList.subList spec.
>> http://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#subList-int-int-
>>

> I think that the proposed fix formally conforms to the spec.

That would surprise me. 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.


>
> However, I'm not really sure why all this details have to be listed in the javadoc.
> Can we just remove them? (with the CCC, of course)

You can't remove specs that subclass implementations were allowed to
depend on unless you can prove (not just test) that there are no
consequences. (I suppose the CCC might decide otherwise.)

>
>> The reason that flattened forms were not used is that each
>> layer does not in general know the class of its parent.
>>
>
> I'm inclined to create another regression test which will systematically check
> the behavior of sublists.

How would you do so for arbitrary AbstractList subclasses?


>> It would be possible (and easy) to create a specialization for the
>> java.util.Arrays.ArrayList class (i.e., the kind returned by
>> Arrays.asList(a).subList), which would also fix the SOE problem
>> in this particular case.
>>
>
> Yes.  The same can be done for Collections.SingletonList too.
> If AbstractList had a base class, that implements sublists without tracking down
> any structural modifications, it could be used as the base class for
> Arrays.ArrayList and Collections.SingletonList.
>
> I think it should better be done as a separate enhancement, though.
>

Conservatively, this solution seems OK as the *only* enhancement;
it avoids the reported SOE, and has no further unintended consequences.

-Doug