May 2025 - core-libs-dev

RFR: 8352171: Arrays.hashCode for sub-range of byte array API addition
by Zihao Lin 06 Mar '26

06 Mar '26

Add the java.util.Arrays.hashCode(byte[], int start, int end). Hi team, I am new here, please give me some guidance. Thank you. ------------- Commit messages: - 8352171: Arrays.hashCode for sub-range of byte array API addition Changes: https://git.openjdk.org/jdk/pull/24128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352171 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24128/head:pull/24128 PR: https://git.openjdk.org/jdk/pull/24128

6 17

RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface
by Tagir F. Valeev 13 Feb '26

13 Feb '26

Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html The specification is mostly composed of Math.min/max and Collections.min/max specifications. The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. ------------- Commit messages: - Fix linebreaks - JDK-8356995 Provide default methods min(T, T) and max(T, T) in Comparator interface Changes: https://git.openjdk.org/jdk/pull/25297/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356995 Stats: 112 lines in 2 files changed: 110 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297 PR: https://git.openjdk.org/jdk/pull/25297

10 37

RFR: 8348828: Windows dll loading now resolves symlinks
by Benjamin Peterson 11 Feb '26

11 Feb '26

Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. ------------- Commit messages: - 8348828: Windows dll loading now resolves symlinks Changes: https://git.openjdk.org/jdk/pull/24694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348828 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694

6 49

RFR: 8347009: Speed up parseInt and parseLong
by Shaojin Wen 09 Feb '26

09 Feb '26

This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. ------------- Commit messages: - optimize parseInt & parseLong - optimize parseInt & parseLong - reuse isDigit - optimize parseInt - optimize parseLong - add benchmark Changes: https://git.openjdk.org/jdk/pull/22919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347009 Stats: 141 lines in 4 files changed: 65 ins; 16 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919

7 67

RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava
by Brian Burkhalter 04 Feb '26

04 Feb '26

This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. ------------- Commit messages: - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337143 Stats: 1265 lines in 75 files changed: 631 ins; 523 del; 111 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317

6 102

RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
by Chen Liang 30 Jan '26

30 Jan '26

Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well. To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks. ------------- Commit messages: - Remove redundant try-catch in getEnclosingMethod/Constructor - Merge branch 'test/signature-error' into feature/new-generic-info - Fix everything - Fixxes - Stage - Stage new tests - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info - ... and 5 more: https://git.openjdk.org/jdk/compare/8aeada10...4110c13f Changes: https://git.openjdk.org/jdk/pull/19281/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19281&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333377 Stats: 4605 lines in 66 files changed: 1027 ins; 3483 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/19281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19281/head:pull/19281 PR: https://git.openjdk.org/jdk/pull/19281

4 20

RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
by Severin Gehwolf 23 Jan '26

23 Jan '26

Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). This patch addresses this issue by: 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been proposed in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. Thoughts? Testing: - [ ] GHA - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems - [x] Some manual testing using systemd slices ------------- Depends on: https://git.openjdk.org/jdk/pull/17198 Commit messages: - 8336881: [Linux] Support for hierarchical limits for Metrics Changes: https://git.openjdk.org/jdk/pull/20280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336881 Stats: 1511 lines in 24 files changed: 1260 ins; 152 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280

3 32

RFR: 8315585: Optimization for decimal to string
by Shaojin Wen 23 Jan '26

23 Jan '26

Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code ------------- Commit messages: - simplify and comments - simplify - simplify - code style - revert change - bug fix - bug fix - refactor - Revert "simplify scale2" - simplify scale2 - ... and 15 more: https://git.openjdk.org/jdk/compare/f446cefe...cb88e0ef Changes: https://git.openjdk.org/jdk/pull/23310/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23310&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315585 Stats: 448 lines in 3 files changed: 237 ins; 118 del; 93 mod Patch: https://git.openjdk.org/jdk/pull/23310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23310/head:pull/23310 PR: https://git.openjdk.org/jdk/pull/23310

7 22

RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException
by Liam Miller-Cushon 27 Nov '25

27 Nov '25

This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. ------------- Commit messages: - Use AbstractImmutableSet - Throw UOE for all Map.of().entrySet() mutator methods - 8328821: Make the ImmutableCollections clear() call consistent Changes: https://git.openjdk.org/jdk/pull/18522/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328821 Stats: 36 lines in 2 files changed: 35 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522 PR: https://git.openjdk.org/jdk/pull/18522

6 51

RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562
by kieran-farrell 19 Nov '25

19 Nov '25

With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/) this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. The specification requires embedding the current timestamp in milliseconds into the first bits 0–47. The version number in bits 48–51, bits 52–63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64–65. The remaining bits 66–127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7) The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: - random-byte-only - 99.8% - higher-precision - 3.5% - counter-based - 0% Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: - random-byte-only 143.487 ± 10.932 ns/op - higher-precision 149.651 ± 8.438 ns/op - counter-based 245.036 ± 2.943 ns/op The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. ------------- Commit messages: - update to add ns percision - 3 variantions - UUID src and test Changes: https://git.openjdk.org/jdk/pull/25303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334015 Stats: 108 lines in 2 files changed: 104 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303

14 126