default random access list spliterator

Peter Levart peter.levart at gmail.com
Mon Mar 7 11:47:14 UTC 2016


What about a Spliterator based on List.subList() method? While the 
specification of List.subList() does not guarantee any specific behavior 
when underlying list is structurally modified, the implementations (at 
least implementations in JDK based on AbstractList) do have a fail-fast 
behavior and there's a chance other implementations too.

Regards, Peter

On 03/07/2016 11:08 AM, Paul Sandoz wrote:
> Hi Michael,
>
> It could, stay tuned for some possible action on this.
>
> This is something we did discuss a while ago [1]. At the time we thought most List implementations would override so did not bother, and admittedly with the frenzy of all other stuff got de-prioritized. But, perhaps we underestimated the integration with existing libraries?
>
> To do that we would need to adjust the specification of the default behaviour which would also adjust the fail-fast behaviour as Tagir points out (which may be a reasonable compromise in the case, it should be possible to detect certain co-mod cases)
>
> Paul.
>
> [1] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-May/001770.html <http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-May/001770.html>
>
>> On 7 Mar 2016, at 10:02, Michael Hixson <michael.hixson at gmail.com> wrote:
>>
>> The default List.spliterator() is iterator-based.  Could this be
>> improved for random access lists, using List.get(int) to fetch
>> elements instead of List.iterator()?
>>
>> I think it could improve most on Spliterator.trySplit().  The current
>> implementation allocates a new array for split-off elements.  I see
>> almost twice the throughput from list.parallelStream().forEach(...)
>> with a custom get(int)-based implementation over the default one.
>>
>> For example, instead of this:
>>
>>     default Spliterator<E> spliterator() {
>>         return Spliterators.spliterator(this, Spliterator.ORDERED);
>>     }
>>
>> I'm suggesting something like this:
>>
>>     default Spliterator<E> spliterator() {
>>         return (this instanceof RandomAccess)
>>                 ? Spliterators.randomAccessListSpliterator(this)
>>                 : Spliterators.spliterator(this, Spliterator.ORDERED);
>>     }
>>
>> where randomAccessListSpliterator is new code that looks a lot like
>> Spliterators.ArraySpliterator.
>>
>> -Michael




More information about the core-libs-dev mailing list