JDK-8234423 : Modifying ArrayList.subList().subList() resets modCount of subList
- Type: Bug
- Component: core-libs
- Sub-Component: java.util:collections
- Affected Version: 11,14
- Priority: P3
- Status: Closed
- Resolution: Fixed
- Submitted: 2019-11-19
- Updated: 2020-06-16
- Resolved: 2020-01-14
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 11 | JDK 13 | JDK 14 | JDK 15 |
|---|---|---|---|
| 11.0.7-oracleFixed | 13.0.4Fixed | 14 b32Fixed  |
15Fixed |
Related Reports
|
Relates :
|
Description
When a sublist of a sublist is created, its modCount is copied from the root ArrayList, not the immediate parent. This means that modifying that 2nd-level sublist will reset the modCount of its parent, so it won't detect concurrent modifications to the root. Similar issue is happening with the sublist's iterator: When an iterator for an ArrayList.SubList is created, its��expectedModCount is set to root.modCount (i.e. the modCount of the ArrayList), while it would be more accurate to set it to��SubList.this.modCount (i.e. the modCount of the SubList). With the current implementation, if the root ArrayList is modified immediately before creating the SubList.iterator not via this SubList, the iterator will fail to detect the concurrent modification.
Comments
|