default random access list spliterator

[Paul Sandoz]

> On 7 Mar 2016, at 12:35, Michael Hixson <michael.hixson at gmail.com> wrote:
> 
> Hi Tagir, Paul,
> 
> Ah, it looks like Donald Raab had exactly the same suggestion.  Sorry
> for the repeat.  I was following that list at that time, and now I'm
> wondering whether my idea was my own.  I agree with everything he
> said.
> 
>> One problem which would arise is that such spliterator will not be able to properly track modCount and throw ConcurrentModificationException.
> 
> Putting this in AbstractList instead of List sounds fine.

That will not work for all libraries (some don’t use AbstractList, such as GS/Eclipse collections).


> I bet you
> could detect *more* co-mod cases and still improve performance, given
> that the current implementation dumps half of the elements into
> Spliterators.ArraySpliterator, which knows nothing about
> modifications.
> 

Certainly there is no doubt leveraging the random-access property is of benefit performance-wise.


>> But, perhaps we underestimated the integration with existing libraries?
> (from the previous thread)
>> The efficacy question is: what List implementations implement RA that  don't already have their own specialized spliterator?
> 
> Spliterator is pretty tough to implement.  AbstractList is easy.  I
> bet most List *views* (as opposed to complete storage) will extend
> AbstractList and provide get(int) and size(), and maybe a couple of
> other methods, but not the full catalog.  That is my experience
> anyway.
> 

Surfacing on AbstractList would be my backup solution if we cannot surface it on List, which i think we can where polling size() is sufficient for a best-effort basis IMO.

Paul.