RFR: 8079136: Accessing a nested sublist leads to StackOverflowError
ivan.gerasimov at oracle.com
Mon Mar 21 12:39:30 UTC 2016
As the CCC request has been approved, the change is ready to be integrated.
Here's the latest variant of the webrev:
It differs from the previous revision only in the javadoc section of
All the code changes are identical.
I'm planning to push the change later this week, unless there are
On 28.01.2016 11:44, Ivan Gerasimov wrote:
> Hello everyone!
> I'd like to respin the discussion.
> The previous attempt can be found here:
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136
> WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/05/webrev/
> Here's the summary of the proposed changes:
> Sublist of an AbstractList (AbstractList.SubList class) now maintains
> a link to the root AbstractList, and not only to the immediate parent
> This allows to perform modifications on the chain of sub-lists in a
> loop instead of using recursion (which, in particular, helps avoid the
> stack-overflow problem).
> The sublist is still backed by its parent list, in sense that all the
> modifications are correctly reflected in the backing list (as well as
> in all the grand parents the sublist, if any), so the fix does not
> violate the existing specification.
> It is proposed to update the spec of AbstractList.subList() in the
> @implSpec section by removing the words about private fields.
> With the fix, some of those private fields are removed.
> A similar change is proposed for the ArrayList.SubList class.
> Two regression tests are added:
> NestedSubList.java - demonstrates a stack-overflow problem when
> dealing with a long chain of sublists,
> SubList.java - tests basic functionality of sub-lists, which helps us
> make sure nothing is broken with the proposed change.
> If people agree that the fix is good, I'll file a CCC request for
> changing the spec of AbstractList.subList().
> Sincerely yours,
More information about the core-libs-dev