Spliterator

[Doug Lea]

On 11/27/12 22:24, Brian Goetz wrote:
>>>   isPredictableSplits  // can always return false
>>
>> Is there any potential use that is not covered by
>> knowing min/max of current and subtask splits?
>
> Yes.  The idea here is that the spliterator knows its split sizes *all the way
> down*.  Which means that you can go straight to direct packing / indexing at the
> leaves.

If minCount==maxCount on current (after calling split) and subtask,
then you know that subtask can use offset indexes. If this is ever
false on your way down, you need to resort to slower form anyway.

In cases where the source is a RandomAccess List with fixed
size (at least for the duration of the operation),
you will at some point be indexing them anyway, so a specialization
still seems warranted. And considering that the particular case of
ArrayList accounts for for a sizable percentage of all collections
usage, I'd hardwire all the (seq and par) stream ops for it anyway.
No sense doing otherwise. In fact, if there are specilaizations
for ArrayList (and T[] arrays), I wouldn't bother with more general
subinterfaces or additional support methods for these cases until
there was a demonstrated need.

BTW about a previous question wrt ConcurrentModificationException.
Remember that, despite its name, this method has little to do with
concurrency. It normally catches only those iterator loops in which
you are modifying the structure of the thing you are iterating (as in,
adding elements) inside the iterator loop. (There are no volatiles
in "modCount" mechanics.) So the specialized implementation of forEach
in ArrayList can ignore modCounts and traverse at full speed.


-Doug