Missing offset+length Arrays.hashCode() methods?

[Roger Riggs]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250317/2e1b5edb/attachment-0001.htm>