Performance of default Spliterators

[Brian Goetz]

Entirely reasonable.  Actually, might not even need much implementing. 
You could do:

   return IntStream.range(0, size()).map(List::get);

(if you could tolerate the early binding to size.)

The efficacy question is: what List implementations implement RA that 
don't already have their own specialized spliterator?

On 5/9/2013 7:53 PM, Raab, Donald [Tech] wrote:
> Apologies if this was already discussed, thought about, planned or in
> progress.
> Right now in the build I am using (about a week old) spliterator returns
> the following:
>      default Spliterator<E> spliterator() {
>          return Spliterators.spliterator(this, Spliterator.ORDERED);
>      }
> For ArrayList this is overridden to return an ArrayListSpliterator.  I
> think there should be an instance of check in spliterator to check for
> RandomAccess so performance is better for other RandomAccess lists that
> might be implemented in other libraries. So the following code would
> need to be changed from this:
>      public static <T> Spliterator<T> spliterator(Collection<? extends T> c,
>                                                   int
> additionalCharacteristics) {
>          return new IteratorSpliterator<>(Objects.requireNonNull(c),
>                                           additionalCharacteristics);
>      }
> To this:
>      public static <T> Spliterator<T> spliterator(Collection<? extends T> c,
>                                                   int
> additionalCharacteristics) {
>          if (c instanceof RandomAccess)
>          return new RandomAccessSpliterator<>(c, additionalCharacteristics);
>          return new IteratorSpliterator<>(Objects.requireNonNull(c),
>                                           additionalCharacteristics);
>      }
> RandomAccessSpliterator would of course need to be implemented.
> Thoughts?  Make sense?  Already planned?