RFR: 8332826: Make hashCode methods in ArraysSupport friendlier [v2]
Pavel Rappo
prappo at openjdk.org
Tue May 28 22:13:01 UTC 2024
On Tue, 28 May 2024 20:38:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:
>> 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.
I believe, it should be `1`. Hear me out. In this method, the `length` is scaled down, whereas in `StringUTF16` it is not. In this method, it's `length`, in `StringUTF16` it's `((byte[]) value).length`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617941436
More information about the security-dev
mailing list