Spliterator.IMMUTABLE

[Doug Lea]

On 03/10/13 09:35, Remi Forax wrote:
> On 03/10/2013 02:35 PM, Doug Lea wrote:
>> On 03/10/13 09:26, Remi Forax wrote:
>>> I've just discovered Spliterator.IMMUTABLE,
>>> I think this flag has the wrong name, given it doesn't mean that the Spliterator
>>> is immutable (usually tryAdvance change the state of the Spliterator) but the
>>> fact that it doesn't act as a view of the collection that creates it.
>>>
>>
>> ... and CONCURRENT doesn't mean that the Spliterator is concurrent.
>> And so on. As stated in the javadocs, spliterator characteristics apply
>> to the elements and/or their sources, not the Spliterators themselves.
>> Maybe this could be better clarified in the javadocs.
>
> Spliterator.IMMUTABLE doesn't means that the source is immutable too,
> it means that even if the elements of the source changed after creation,
> the element pushed by the Spliterator will not changed.
>

This is too Collections-centric a view. Spliterator.characteristics
are intended to apply across anything you can define a Spliterator for.
(They include a few properties that are not yet exploited much in Streams.)

As far as a user of a Spliterator is concerned, there are three
cases of potential interest here:

CONCURRENT: The structure (e.g., number, order) and/or elements are allowed
to change dynamically and in such cases are traversed under a given
defined semantics.

IMMUTABLE: The structure and elements cannot change during traversal.

[Other] Any change in structure and/or elements represents a usage error,
in which case the Spliterator is expected to have a documented course
of action upon any detected change (normally a best-effort 
ConcurrentModificationException check).

Now, whether an IMMUTABLE spliterator arises because the source is
immutable (for example a raw input stream) or because it
is a snapshot (for example CopyOnWriteArrayList) doesn't matter.

Does that help?

-Doug