Missing offset+length Arrays.hashCode() methods?

[Remi Forax]

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.riggs at oracle.com>
> To: "core-libs-dev" <core-libs-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250317/1f3b7144/attachment.htm>