- core-libs-dev - openjdk.org

RFR: 8379441: Refactor jaxp/javax catalog tests to use JUnit
by David Beaumont 08 Mar '26

08 Mar '26

95% automated migration (search and replace). A handful of slightly note-worthy tweaks (called out with inline comments). The majority/automated changes are: * Convert to JUnit assertions (oddly, very few places) * Convert to JUnit data providers (almost all tests) * Convert test to use assertThrows (many tests) * Make util methods static (needed for data providers, but done everywhere for consistency) * Organise imports ------------- Commit messages: - 8379441: Refactor jaxp/javax catalog tests to use JUnit Changes: https://git.openjdk.org/jdk/pull/30124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379441 Stats: 564 lines in 28 files changed: 128 ins; 152 del; 284 mod Patch: https://git.openjdk.org/jdk/pull/30124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30124/head:pull/30124 PR: https://git.openjdk.org/jdk/pull/30124

2 3

RFR: 8364007: Add overload without arguments to codePointCount in String etc.
by Tatsunori Uchino 08 Mar '26

08 Mar '26

Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { throw new Exception("exceeding length"); } Is a CSR required to this change? ------------- Commit messages: - Remove trailing spaces - 8364007: Add overload without arguments to codePointCount in String etc. Changes: https://git.openjdk.org/jdk/pull/26461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364007 Stats: 112 lines in 13 files changed: 95 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461

7 91

[External] : Confusion about Stream side-effects
by Jige Yu 08 Mar '26

08 Mar '26

Hi @core-libs-dev, I am looking to validate the following idiom: Stream.iterate(seed, e -> e.nextOrNull()) .takeWhile(Objects::nonNull); The intent is for the stream to call nextOrNull() repeatedly until it returns null. However, I am concerned about where the Stream specification guarantees the correctness of this approach regarding happens-before relationships. The iterate() Javadoc defines happens-before for the function passed to it, stating that the action of applying f for one element happens-before the action of applying it for subsequent elements. However, it seems silent on the happens-before relationship with downstream operations like takeWhile(). My concern stems from the general discouragement of side effects in stream operations. For example, relying on side effects between subsequent map() calls is considered brittle because a stream might invoke the first map() on multiple elements before the second map() processes the first element. If this theory holds, is there anything theoretically preventing iterate() from generating multiple elements before takeWhile() evaluates the first one? I may be overthinking this, but I would appreciate your insights into why side effects are discouraged even in ordered, sequential streams and whether this specific idiom is safe. Appreciate your help! Best regards, Jige Yu

3 13

RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out
by Doug Lea 07 Mar '26

07 Mar '26

Changes signal filtering to avoid possible starvation ------------- Commit messages: - signalWork diagnostic - filter by index - For testing Changes: https://git.openjdk.org/jdk/pull/28797/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373118 Stats: 70 lines in 1 file changed: 44 ins; 5 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/28797.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797 PR: https://git.openjdk.org/jdk/pull/28797

3 126

RFR: 8379437: Refactor ProcessBuilder and ProcessHandle tests to JUnit
by Roger Riggs 07 Mar '26

07 Mar '26

Refactor ProcessBuilder and ProcessHandle tests to use Junit instead of TestNG. Remove old main testng driver stubs that allowed tests to be run from the command line. ------------- Commit messages: - JDK-8379437: Refactor ProcessBuilder and ProcessHandle tests to JUnit Changes: https://git.openjdk.org/jdk/pull/30128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379437 Stats: 293 lines in 7 files changed: 15 ins; 86 del; 192 mod Patch: https://git.openjdk.org/jdk/pull/30128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30128/head:pull/30128 PR: https://git.openjdk.org/jdk/pull/30128

1 0

RFR: 8379195: Refactor Arrays TestNG tests to use JUnit
by Raffaello Giulietti 07 Mar '26

07 Mar '26

A migration from TestNG to JUnit ------------- Commit messages: - 8379195: Refactor Arrays TestNG tests to use JUnit Changes: https://git.openjdk.org/jdk/pull/30111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379195 Stats: 196 lines in 7 files changed: 53 ins; 27 del; 116 mod Patch: https://git.openjdk.org/jdk/pull/30111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30111/head:pull/30111 PR: https://git.openjdk.org/jdk/pull/30111

2 9

RFR: 8379344: Compact the Unicode/CLDR version tables
by Naoto Sato 07 Mar '26

07 Mar '26

Minor Javadoc fix to `java.lang.Character` and `java.util.spi.LocaleServiceProvider`, which list supported Unicode/CLDR versions. Since the tables grow with each JDK release, older releases should be coalesced. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/30099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379344 Stats: 25 lines in 2 files changed: 24 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/30099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30099/head:pull/30099 PR: https://git.openjdk.org/jdk/pull/30099

4 10

RFR: 8377907: (process) Race in ProcessBuilder can cause JVM hangs
by Thomas Stuefe 07 Mar '26

07 Mar '26

When starting child processes from Java, we bootstrap the child process after fork and before exec. As part of that process, up to five pipes are handed to the child: three for stdin/out/err, respectively, and two internal communication pipes (fail and childenv). If, concurrently with our invocation of `ProcessBuilder.start()`, third-party native code forks a child of its own, the natively forked child carries copies of these pipes. It then may keep these pipes open. This results in various forms of communication errors, most likely hangs - either in `ProcessBuilder.start()`, or in customer code. In the customer case that started this investigation, `ProcessBuilder.start()` hung intermittently when using a third-party Eclipse library that happened to perform forks natively. The JVM has no full control over what happens in its process, since we allow native code to run. Therefore, native forks can happen, and we have to work around them. The fix makes sure that the pipes we use in ProcessBuilder are always tagged with CLOEXEC. Since forks are typically followed by execs, this will close any file descriptors that were accidentally inherited. ### FORK/VFORK mode Here, it is sufficient to open all our pipes with O_CLOEXEC. The caveat here is that only Linux offers an API to do that cleanly: `pipe2(2)` ([1]). On MacOS and AIX, we don't have `pipe2(2)`, so we need to emulate that behavior using `pipe(2)` and `fcntl(2)` in quick succession. That is still racy, since we did not completely close the time window within which pipe file descriptors are not O_CLOEXEC. But this is the best we can do. ### POSIX_SPAWN mode Creating the pipes with CLOEXEC alone is not sufficient. With `posix_spawn(3)`, we exec twice: first to load the jspawnhelper (inside `posix_spawn(3)`), a second time to load the target binary. Pipes created with O_CLOEXEC would not survive the first exec. Therefore, instead of manually `dup2(2)`'ing our file descriptors after the first exec in jspawnhelper itself, we set up dup2 file actions to let posix_spawn do the dup'ing. According to POSIX, these dup2 file actions will be processed before the kernel closes the inherited CLOEXEC file descriptors. Unfortunately, macOS is again not POSIX-compliant, since the macOS kernel can close CLOEXEC file descriptors before posix_spawn processes them in its dup2 file actions. As a workaround for that bug, we create temporary copies of the pipe file descriptors that are untagged with CLOEXEC and use them as sources for posix_spawn dup2 actions. Of course, these file descriptor copies would again leak to concurrently forked processes. But since these are only temporary copies, that is benign. ### Code changes We replace the manual file descriptor dup'ing in jspawnhelper with posix_spawn file actions. That means we can scrap everything associated with that: it is no longer necessary to pass file descriptors via command-line arguments to jspawnhelper or via the `ChildStuff` structure. However, I tried to keep code reshuffling minimal and this patch as small as possible. While working on this code, I had a number of ideas for streamlining and improvements, but I will hold that off for future RFRs. This patch aims to be small and easily backportable. ----------- Testing: The patch adds three new tests: 1) `ConcNativeForkTest` is a reproducer for the "native concurrent forks cause hangs in ProcessBuilder.start()" problem. It is pretty good at provoking hangs in unpatched JVMs. However, it is not suited for automated CI/CD environments since it essentially fork-bombs itself. Therefore, I marked the test as "manual". 2) `PipesCloseOnExecTest` is a modified variant of `ConcNativeForkTest` that, instead of executing concurrent native forks, continuously checks that no file descriptors pop up untagged with CLOEXEC during a `ProcessBuilder` invocation. This test is fast and reliable, but it works only on Linux, since only with `pipe2(2)` we can completely close the !CLOEXEC time window. On MacOS and AIX, the test correctly spots untagged file descriptors since we still have the small time window between `pipe(2)` and `fcntl(2)`. 3) Finally, `FDLeaks` is a complementary test that checks that we don't accumulate unclosed file descriptors in ProcessBuilder.start(). - All tests in java/lang/ProcessBuilder were run, and all issues fixed. In particular, I tested: - Linux x64 with glibc - Linux x64 with muslc (Alpine) - MacOS Arm64 - Ran jdk + hotspot tier1 on Linux x64 - Tests on AIX are ongoing at SAP - GHAs ran through successfully [1] https://linux.die.net/man/2/pipe2 ------------- Commit messages: - wip - copyrights - new test - start Changes: https://git.openjdk.org/jdk/pull/29939/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29939&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377907 Stats: 1250 lines in 16 files changed: 1123 ins; 54 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/29939.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29939/head:pull/29939 PR: https://git.openjdk.org/jdk/pull/29939

6 28

RFR: 8371795: Improve documentation of Class.isInstance
by Chen Liang 07 Mar '26

07 Mar '26

The 3 methods to determine conversions and subtyping on `java.lang.Class`, which are `isInstance`, `cast`, and `isAssignableFrom`, have their documentation from the earliest days of the Java Platform. During the language evolution, a lot of terms have become inaccurate, such as "assignment-compatible", which does not apply for primitive types, and the out-of-date instanceof analogy with the upcoming patterns, in `isInstance`; `isAssignableFrom` is not very clear about arrays; `cast` would also benefit from more detailed explanations. In my facelift, I moved the subtyping description to `isAssignableFrom`, and left the conversion stuff in `isInstance` and `cast`. I intentionally avoided linking to too many JLS chapters to reduce confusions. I believe in this shape, we have a good amount of easily comprehensible yet accurate specification for all 3 methods, and users are welcome to read the linked JLS chapters for more details and context. ------------- Commit messages: - Improve documentation of Class.isInstance Changes: https://git.openjdk.org/jdk/pull/28684/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371795 Stats: 90 lines in 1 file changed: 35 ins; 16 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/28684.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28684/head:pull/28684 PR: https://git.openjdk.org/jdk/pull/28684

5 8

RFR: 8379284: Avoid the need to keep obsolette preview feature constants until bootstrap JDK is upgraded
by Jan Lahoda 07 Mar '26

07 Mar '26

There's an enum `src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java#PreviewFeature.Feature` that defines the current preview features, in particular those that have an API. The API is then marked with the appropriate enum constant. There's a problem with this enum: javac's APIs may also need to use constants from the enum, and as javac is built twice, once with the bootstrap JDK to get the so called "interim javac" (which is then used to compile nearly all the rest of the JDK), and second time to get the final version of javac, this enum needs to be dragged into the interim compilation as well. As a consequence, the bootstrap JDK classfiles are resolved against this up-to-date feature enum. And if any of the bootstrap JDK classfiles would refer to an enum constant that is not part of this up-to-date feature enum, javac would report a warning, failing the build. As a consequence, the guidance is that when a preview feature ceases to be preview (either by maturing to a final and permanent feature, or by removal), we keep the appropriate enum constant as long as the bootstrap JDK may use it. This works, but causes constant confusion, and unnecessary work, as finalizing a preview feature requires another action in the next release to cleanup the enum constant. This PR is exploring an alternative solution: it takes the up-to-date `Feature` enum, and auto-generates a hybrid enum containing constants both from the up-to-date and bootstrap `Feature` enum. As a consequence, the up-to-date enum does not need to contain any legacy constants, as those are automatically injected for the interim build. This hybrid enum should never be used outside of the interim javac build. As a consequence, when a feature ceases to be a preview feature, we can clean up the feature enum immediately, leading to less confusion and less downstream work. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into previewfeature-hybrid-enum-exp - Reflecting review feedback. - Correcting dependencies as suggested. - Cleanup comment. - More logging - Adding logging. - Attempting to fix dependencies. - Produce 'hybrid' PreviewFeature.Feature enum for interim javac instead of manually keeping obsolette constants. Changes: https://git.openjdk.org/jdk/pull/30072/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30072&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379284 Stats: 129 lines in 3 files changed: 97 ins; 19 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/30072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30072/head:pull/30072 PR: https://git.openjdk.org/jdk/pull/30072

5 11