November 2024 - core-libs-dev

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: 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: 8173970: jar tool should have a way to extract to a directory
by Jaikiran Pai 13 Nov '25

13 Nov '25

Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). The commit also includes a jtreg testcase which verifies the usage of this new option. ------------- Commit messages: - 8173970: jar tool should have a way to extract to a directory Changes: https://git.openjdk.java.net/jdk/pull/2752/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173970 Stats: 268 lines in 4 files changed: 262 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752

13 61

RFR: 8306055: Add a built-in Catalog to JDK XML module
by Joe Wang 16 Oct '25

16 Oct '25

Implement the built-in Catalog. ------------- Commit messages: - fix whitespace error - 8306055: Add a built-in Catalog to JDK XML module Changes: https://git.openjdk.org/jdk/pull/16719/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16719&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306055 Stats: 1641 lines in 50 files changed: 1429 ins; 118 del; 94 mod Patch: https://git.openjdk.org/jdk/pull/16719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16719/head:pull/16719 PR: https://git.openjdk.org/jdk/pull/16719

6 19

RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
by Laurent Bourgès 21 Sep '25

21 Sep '25

* Optimized mixed insertion sort * Optimized insertion sort * Optimized Radix sort * Updated microbenchmark I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938 ------------- Commit messages: - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Changes: https://git.openjdk.org/jdk/pull/13568/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8266431 Stats: 4022 lines in 4 files changed: 1747 ins; 1272 del; 1003 mod Patch: https://git.openjdk.org/jdk/pull/13568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568 PR: https://git.openjdk.org/jdk/pull/13568

10 105

RFR: 8342869: Errors related to unused code on Windows after 8339120 in awt
by Julian Waters 08 Sep '25

08 Sep '25

After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did ------------- Commit messages: - 8342869 Changes: https://git.openjdk.org/jdk/pull/21655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342869 Stats: 19 lines in 8 files changed: 5 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/21655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21655/head:pull/21655 PR: https://git.openjdk.org/jdk/pull/21655

5 19

RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs
by Julian Waters 08 Jul '25

08 Jul '25

After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did ------------- Commit messages: - 8342868 Changes: https://git.openjdk.org/jdk/pull/21654/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21654&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342868 Stats: 11 lines in 4 files changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21654.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21654/head:pull/21654 PR: https://git.openjdk.org/jdk/pull/21654

5 23

RFR: 8342682: Errors related to unused code on Windows after 8339120
by Julian Waters 08 Jul '25

08 Jul '25

After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did. This will require reviews from core-libs, awt, security, accessibility, jpackage, and whatever team is responsible for HotSpot debugging. This fix requires C++17, so it will have to wait for the switch to C++17. I will be working towards that in the meantime and addressing the issues that come with changing the language standard elsewhere. This will only go in once the JDK actually starts using C++17 ------------- Commit messages: - Compile as C++17 - 8342682 Changes: https://git.openjdk.org/jdk/pull/21616/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342682 Stats: 72 lines in 25 files changed: 25 ins; 1 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/21616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616 PR: https://git.openjdk.org/jdk/pull/21616

7 54