> On 7 Mar 2016, at 12:35, Michael Hixson <michael.hix...@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.
