8352171: Arrays.hashCode for sub-range of byte array API addition

[linzihao1999]

Add the java.util.Arrays.hashCode(byte[], int start, int end).

Hi team, I am new here, please give me some guidance. Thank you.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires a CSR request matching fixVersion 25 to be approved (needs to be created)

Issue

• JDK-8352171: Arrays.hashCode for sub-range of byte array API addition (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24128/head:pull/24128
$ git checkout pull/24128

Update a local copy of the PR:
$ git checkout pull/24128
$ git pull https://git.openjdk.org/jdk.git pull/24128/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24128

View PR using the GUI difftool:
$ git pr show -t 24128

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24128.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back linzihao1999! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@linzihao1999 The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (57298dc4)
• 00: Full (79de5e97)

[SirYwell]

To me, it seems odd to add only the byte[] variant but not other primitive type arrays (as with the equals methods). You also most likely need a CSR.

[liach]

The a == null special check is dubious - a == null has a meaning if we are hashing a whole byte[] object, but with a specific fromIndex and toIndex it just doesn't work.

That said, we might consider accepting the initial hash too - For example, we have two byte[] arrays and we want a concatenated hash. The initial hash allows us to compute such a hash from two arrays easily.

[RogerRiggs]

None of the other public APIs for hashcode include an initial value argument.
The caller can easily combine the hashcode values themselves as needed.

[linzihao1999]

That’s helpful to know, Let's solve this issue after creating the CSR.

[liach]

/csr

[openjdk]

@liach has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@linzihao1999 please create a CSR request for issue JDK-8352171 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[RogerRiggs]

To me, it seems odd to add only the byte[] variant but not other primitive type arrays (as with the equals methods). You also most likely need a CSR.

The only use case presented was for byte array subranges. While it seems obvious to repeat the pattern for the other types, they might never get used and would just create more surface area to maintain. The Arrays class is already huge.