Just a comment "en passant", array, List or String in Java tend to use the from/to index convention instead of the offset+length convention which is the convention for system calls (read/write etc).
regards, Rémi > From: "Roger Riggs" <roger.ri...@oracle.com> > To: "core-libs-dev" <core-libs-dev@openjdk.org> > Sent: Monday, March 17, 2025 7:42:18 PM > Subject: Re: Missing offset+length Arrays.hashCode() methods? > Hi, > It seems like a reasonable API enhancement, the implementation already > supports > sub-ranges. > Created [ https://bugs.openjdk.org/browse/JDK-8352171 | 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
