Missing offset+length Arrays.hashCode() methods?

[Chen Liang]

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