<div dir="ltr">Hello experts,<div><br></div><div>Firstly, please let me know where to post this question if it is an inappropriate question for this mailing list.</div><div><br></div><div>The java.util.Arrays utility class currently exposes pairs of methods for comparing arrays of primitives and objects, for example:</div><div><br></div><div>    java.util.Arrays#equals(byte[], byte[])</div><div>    java.util.Arrays#equals(byte[], int, int, byte[], int, int)</div><div><br></div><div>However, only a single method is provided for the equivalent hashCode() methods:</div><div><br></div><div>    java.util.Arrays#hashCode(byte[])</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks in advance,</div><div>Matt</div><div><br></div></div>