<i18n dev> RFR: 8332826: Make hashCode methods in ArraysSupport friendlier [v2]

[Claes Redestad]

On Tue, 28 May 2024 19:13:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
> 
>> 273:         return switch (length) {
>> 274:             case 0 -> initialValue;
>> 275:             case 1 -> 31 * initialValue + (a[fromIndex] & 0xff);
> 
> For clarity, if you think it helps:
> Suggestion:
> 
>             case 1 -> 31 * initialValue + Byte.toUnsignedInt(a[fromIndex]);

I don't care as long as microbenchmarks don't get a hiccup.

> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 301:
> 
>> 299:         return switch (length) {
>> 300:             case 0 -> initialValue;
>> 301:             case 1 -> 31 * initialValue + JLA.getUTF16Char(a, fromIndex);
> 
> There seems to be a mismatch here with the original code in StringUTF16, where the length that is tested for is `2` instead of `1`.

Yes, should be `2` (`a` is semantically a `char[]`). This typo likely pass functional testing since `1` can never happen in practice, and the default case should work for any value. There might be a String microbenchmark out there that might be slightly unhappy, though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617867797
PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617865658