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
