[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Claes Redestad claes.redestad at oracle.com
Sat Dec 9 16:04:04 UTC 2017

Hi Andrej,

forEach seems like a no-brainer, but spliterator might require some 
extra care.

For example, returning Spliterators.emptySpliterator() and
Collections.singletonSpliterator when appropriate *sounds* like nice little
optimizations, but Arrays.spliterator(T[]) with an empty or 
single-element array
appears to be relatively cheap operations, whereas mixing implementation 
make call-sites accepting List.of(foo).spliterator() become megamorphic.

Thus I think these should be done independently as a follow-up, along with
tests and microbenchmarks.



On 2017-12-09 11:43, Andrej Golovnin wrote:
> Hi Claes,
>> One more thing: Could you please add specialised implementations also
>> for the following methods:
>> List.forEach(Consumer)
>> List.spliterator()
>>   For List12 when List12.size() == 1 please use Collections.singletonSpliterator()
>>   (this method should be moved to the Spliterators class and be public).
>>   For List12 when List12.size() == 2 please use Arrays.spliterator().
>>   For ListN when List.isEmpty() == true please use Spliterators.emptySpliterator​()
>>   and otherwise use Arrays.spliterator().
> I’m sorry I forgot to mention, that Set12, SetN, Map12 and MapN should also
> have specialised implementations for the #forEach-methods and for
> the #spliterator()-methods in Set12, SetN.
> Thanks!
> Best regards,
> Andrej Golovnin

More information about the core-libs-dev mailing list