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

Semantics of Spliterator.IMMUTABLE and Spliterator.CONCURRENT

    Details

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

      Description

      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.

        Activity

        There are no comments yet on this issue.

          People

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

            Dates

            • Created:
              Updated: