Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8172689

Clarify semantics of Spliterator.IMMUTABLE and Spliterator.CONCURRENT


    • Type: Bug
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 9
    • Fix Version/s: tbd_major
    • Component/s: core-libs
    • Labels:


      CONCURRENT spec: the element source may be safely concurrently modified
      IMMUTABLE spec: the element source cannot be structurally modified

      Now, CopyOnWriteArrayList has an IMMUTABLE spliterator, but from the user's point of view the element source may be the collection itself, which continues to be mutable, so perhaps CONCURRENT is a better fit. But if you regard the source of elements as the "snapshot", then IMMUTABLE is fine. Pehaps better is something like

      IMMUTABLE: the sequence of elements is determined at construction time, and is independent of subsequent actions.

      CONCURRENT: the sequence of elements is safe from CME; weakly consistent.

      Then IMMUTABLE might be a subset of CONCURRENT, i.e. IMMUTABLE implies CONCURRENT.

      Then if a spliterator splits off a subarray, as with IteratorSpliterators, then the sub-spliterator would be IMMUTABLE.

      I think it's quite confusing that the properties of CONCURRENT and IMMUTABLE currently depend on whether the spliterator in question is a sub-spliterator.


          Issue Links



              • Assignee:
                psandoz Paul Sandoz
                martin Martin Buchholz
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: