Hi,
It seems like a reasonable API enhancement, the implementation already
supports sub-ranges.
Created JDK-8352171 <https://bugs.openjdk.org/browse/JDK-8352171>
Arrays.hashCode for sub-range of byte array API addition
Regards, Roger
On 1/31/25 6:45 AM, Matthew Swift wrote:
Hello experts,
Firstly, please let me know where to post this question if it is an
inappropriate question for this mailing list.
The java.util.Arrays utility class currently exposes pairs of methods
for comparing arrays of primitives and objects, for example:
java.util.Arrays#equals(byte[], byte[])
java.util.Arrays#equals(byte[], int, int, byte[], int, int)
However, only a single method is provided for the equivalent
hashCode() methods:
java.util.Arrays#hashCode(byte[])
Specifically, the offset+length versions are not present, despite
there being support in jdk.internal.util.ArraysSupport. Given the
ubiquity of equals + hashCode, I would expect there to be symmetry
between the equals and hashCode APIs in Arrays. The lack of support
means that applications cannot take advantage of intrinsics.
The use-case we have is parsing byte[] network protocol packets into
their components, which are represented using objects containing
offset+length pointers into the original packet. These components are
frequently stored in hash sets and maps. More precisely, we are
parsing ASN.1 BER packets, so our use-case is remarkably similar to
JDK's sun.security.util.DerValue#hashCode, but could be applied
equally to other network protocols.
I know that the String class stopped using the offset+length
low-allocation design some time ago, so perhaps the design I'm
describing above is no longer best-practice thanks to JVM
advancements, and hence there should be no need for offset+length
Arrays#hashCode - but that doesn't explain the asymmetry with
Arrays#equals.
Thanks in advance,
Matt
