Performance of default Spliterators

[Doug Lea]

On 05/10/13 04:33, Paul Sandoz wrote:

> Perhaps it would be better to change the default spliterator() implementation in List, since Collection & RandomAccess is not very useful:
>
>      @Override
>      default Spliterator<E> spliterator() {
>          if (this instanceof RandomAccess) {
>              return new RandomAccessListSpliterator(this);
>          } else {
>              return Spliterators.spliterator(this, Spliterator.ORDERED);
>          }
>      }
>
>
>> RandomAccessSpliterator would of course need to be implemented.
>>
>> Thoughts?  Make sense?  Already planned?
>>
>
> Seems OK to me.
>

My first thought was: anyone able to create a new RandomAccess List is
surely able to write a Spliterator for it, and almost surely a
better one than we could supply as a default, so why burden all
other cases with an extra instanceof check to dispatch to it?

On the other hand, since most/all commonly used forms of Lists will
override default anyway, the impact is surely too small to notice,
so it would be fine to do this.

(The main problem here that we have seen many times is that there
is no named type RandomAccessList, so there is no good place
to put a default.)

-Doug