Indeed, this is a good proposal to reduce unnecessary allocation, especially if the executing thread does not share the array with another thread. FYI for String, I believe the no-low-allocation was mainly due to that Strings may have extended lifespan, and it's not feasible for a small substring to hold a long string (such as a substring in a whole file) not reclaimable by GC. After checking the PR https://github.com/openjdk/jdk/pull/24128, I think there is value in providing an initial hash base (as the internal version) for things like views that source from multiple arrays.
Chen On Mon, Mar 17, 2025 at 1:42 PM Roger Riggs <roger.ri...@oracle.com> wrote: > 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 > > >
