mirror of
https://github.com/openjdk/jdk.git
synced 2025-08-28 07:14:30 +02:00
8306785: fix deficient spliterators for Sequenced Collections
Reviewed-by: psandoz
This commit is contained in:
parent
372d0cf752
commit
743e8b8e0a
6 changed files with 26 additions and 12 deletions
|
@ -1509,7 +1509,10 @@ public class ArrayList<E> extends AbstractList<E>
|
|||
public Spliterator<E> spliterator() {
|
||||
checkForComodification();
|
||||
|
||||
// ArrayListSpliterator not used here due to late-binding
|
||||
// This Spliterator needs to late-bind to the subList, not the outer
|
||||
// ArrayList. Note that it is legal for structural changes to be made
|
||||
// to a subList after spliterator() is called but before any spliterator
|
||||
// operations that would causing binding are performed.
|
||||
return new Spliterator<E>() {
|
||||
private int index = offset; // current index, modified on advance/split
|
||||
private int fence = -1; // -1 until used; then one past last index
|
||||
|
@ -1628,9 +1631,7 @@ public class ArrayList<E> extends AbstractList<E>
|
|||
* be worthwhile in practice. To carry this out, we (1) lazily
|
||||
* initialize fence and expectedModCount until the latest
|
||||
* point that we need to commit to the state we are checking
|
||||
* against; thus improving precision. (This doesn't apply to
|
||||
* SubLists, that create spliterators with current non-lazy
|
||||
* values). (2) We perform only a single
|
||||
* against; thus improving precision. (2) We perform only a single
|
||||
* ConcurrentModificationException check at the end of forEach
|
||||
* (the most performance-sensitive method). When using forEach
|
||||
* (as opposed to iterators), we can normally only detect
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue