On Mon, 26 Jan 2026 16:01:11 GMT, Chen Liang <[email protected]> wrote:
>> Oli Gillespie has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix failing test
>
> src/java.base/share/classes/java/util/TreeMap.java line 2028:
>
>> 2026: }
>> 2027:
>> 2028: public abstract Spliterator<Map.Entry<K,V>> spliterator();
>
> I don't think you need this huge a patch. I think you should just do:
> Suggestion:
>
> public Spliterator<Map.Entry<K,V>> spliterator() {
> return Spliterators.spliterator(iterator(),
> Spliterator.DISTINCT);
> }
>
> Your patch is introducing spliterator behavioral changes unrelated to the
> performance regression fix.
Thanks for looking.
I suppose you mean Spliterators.spliteratorUnknownSize?
Hmm - I made the change this way to be consistent with the existing
`SubMapKeyIterator` and `DescendingSubMapKeyIterator`, simply adding the same
functionality for the Entry versions. Do you think *those* are overcomplicated
too, or there's a reason they're like that that doesn't apply to the Entry
versions? I don't know why they were originally added, to be honest, I didn't
find much useful context in the history.
I don't know Spliterator well enough to spot any subtle behavioural
differences, that's one reason I chose to follow the existing patterns.
DescendingSubMapEntryIterator is SORTED but SubMapEntryIterator is not, so I'd
have to account for that too.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2733284522
