default random access list spliterator
paul.sandoz at oracle.com
Mon Mar 7 12:55:49 UTC 2016
> 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
>> 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
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
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.
More information about the core-libs-dev