- core-libs-dev - openjdk.org

RFR: 8378580: Make ArrayDeque bulk add methods bootstrap-proof
by Eirik Bjørsnøs 25 Feb '26

25 Feb '26

Please review this small change to avoid loading lambda machinery in `ArrayDeque.addAll` and `ArrayDeque(Collection)`. Core collections like these may be useful in early bootstrap where we want to avoid eager loading of lambda machinery. JDK-8375580 recently showed one example where `URLClassPath` was avoiding these bulk-adding methods exactly to avoid triggering lambdas. This PR replaces the use of `Collection.forEach` with a plain old for loop. This was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2026-February/159362.html Cleanup, low risk enhancement, `noreg-cleanup`. ------------- Commit messages: - Use simple loop instead of lambda in ArrayDeque bulk adds Changes: https://git.openjdk.org/jdk/pull/29894/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29894&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378580 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29894.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29894/head:pull/29894 PR: https://git.openjdk.org/jdk/pull/29894

2 4

RFD: ArrayDeque bulk adds and lambda
by Eirik Bjørsnøs 24 Feb '26

24 Feb '26

Hi, While working on JDK-8375580, I noticed the following code and comment in URLClassPath: // can't use ArrayDeque#addAll or new ArrayDeque(Collection); // it's too early in the bootstrap to trigger use of lambdas [..] for (int i = 0; i < size; i++) unopenedUrls.add(path.get(i)); This code avoids using bulk add operations on ArrayDeque, presumably to work around problems caused by early initialization of lambda machinery. And indeed, in ArrayDeque::copyElements, we find this: c.forEach(this::addLast); While I don't know if the above code is still a concern, should we consider replacing it with a simple for loop, like this: for (E e : c) { addLast(e); } Can this make ArrayDeque somewhat safer to use in early bootstrap code? Wdyt? Eirik.

2 3

RFR: 8376483: Avoid loading java.nio.charset.StandardCharsets in java.util.zip.ZipCoder
by Eirik Bjørsnøs 24 Feb '26

24 Feb '26

Please review this class which removes a dependency on `java.nio.charset.StandardCharsets` introduced in [JDK-8365703](https://bugs.openjdk.org/browse/JDK-8365703). We can use `UTF_8.INSTANCE` here as elsewhere in this class to prevent startup regression loading otherwise unused classes and charsets. Verified that running `java -cp hello.jar Hello" observes the following diff in loaded classes when run with this PR: < java.nio.charset.StandardCharsets < sun.nio.cs.US_ASCII < sun.nio.cs.ISO_8859_1 < sun.nio.cs.UTF_16BE < sun.nio.cs.UTF_16LE < sun.nio.cs.UTF_16 < sun.nio.cs.UTF_32BE < sun.nio.cs.UTF_32LE < sun.nio.cs.UTF_32 This is a strict refactoring, no tests updated, `noreg-trivial`. ------------- Commit messages: - Avoid loading java.nio.charset.StandardCharsets Changes: https://git.openjdk.org/jdk/pull/29443/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29443&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376483 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29443/head:pull/29443 PR: https://git.openjdk.org/jdk/pull/29443

3 4

RFR: 8373186: Improve readability of core reflection toString specifications
by Joe Darcy 24 Feb '26

24 Feb '26

Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types. ------------- Commit messages: - JDK-8373186: Improve readability of core reflection toString specifications Changes: https://git.openjdk.org/jdk/pull/28688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373186 Stats: 33 lines in 1 file changed: 9 ins; 6 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/28688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28688/head:pull/28688 PR: https://git.openjdk.org/jdk/pull/28688

5 10

RFR: 8378354: Faulty assertion in checkInvariants method of ConcurrentHashMap
by cdw200806 24 Feb '26

24 Feb '26

"In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red." ------------- Commit messages: - Update ConcurrentHashMap.java Changes: https://git.openjdk.org/jdk/pull/24612/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24612&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378354 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24612/head:pull/24612 PR: https://git.openjdk.org/jdk/pull/24612

7 18

RFR: 8378354: Faulty assertion in checkInvariants method of ConcurrentHashMap
by cdw200806 24 Feb '26

24 Feb '26

Raise a new PR. for https://github.com/openjdk/jdk/pull/24612 is too old. "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red." ------------- Commit messages: - Fix red-black tree invariant check in ConcurrentHashMap Changes: https://git.openjdk.org/jdk/pull/29857/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378354 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29857/head:pull/29857 PR: https://git.openjdk.org/jdk/pull/29857

4 6

RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on Windows
by David Beaumont 24 Feb '26

24 Feb '26

Removed the manual file tidyup on the expectation that jtreg will sort that all out. Switched to using Utils.createTempFile() while I was there. ------------- Commit messages: - Remove file cleanup and switch to Utils.createTempFile() Changes: https://git.openjdk.org/jdk/pull/29783/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29783&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378118 Stats: 46 lines in 1 file changed: 2 ins; 23 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/29783.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29783/head:pull/29783 PR: https://git.openjdk.org/jdk/pull/29783

4 10

RFR: 8377506: Implementation of PEM Encodings of Cryptographic Objects (Final)
by Anthony Scarpino 24 Feb '26

24 Feb '26

Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524) include: - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text. - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter. - A new `CryptoException` indicates failures during cryptographic processing at runtime. thanks ------------- Commit messages: - Merge branch 'master' into pem27 - doc and test updates - Initial Changes: https://git.openjdk.org/jdk/pull/29640/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29640&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377506 Stats: 752 lines in 33 files changed: 272 ins; 182 del; 298 mod Patch: https://git.openjdk.org/jdk/pull/29640.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29640/head:pull/29640 PR: https://git.openjdk.org/jdk/pull/29640

5 13

RFR: 8378378: Remove references to obsolete jdk.net.usePlainDatagramSocketImpl property from tests
by Jaikiran Pai 24 Feb '26

24 Feb '26

Can I please get a review of this test-only change which removes reference to the obsolete `jdk.net.usePlainDatagramSocketImpl` property? This property and the related fallback support was removed in https://bugs.openjdk.org/browse/JDK-8253119. The property plays no role anymore. The tests continue to pass after this change. ------------- Commit messages: - remove references to obsolete jdk.net.usePlainDatagramSocketImpl property Changes: https://git.openjdk.org/jdk/pull/29871/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29871&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378378 Stats: 79 lines in 3 files changed: 0 ins; 50 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/29871.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29871/head:pull/29871 PR: https://git.openjdk.org/jdk/pull/29871

4 6

RFR: 8377905: gcc.md included with every build
by Mikael Vidstedt 24 Feb '26

24 Feb '26

JDK-8377509 added the gcc.md license file. Unfortunately the file is unconditionally in the built JDK regardless of the toolchain used. This change updates the build logic to only include the file when relevant. Testing: tier1, builds-tier[2-5], manual verification to ensure the file is only included where expected. ------------- Commit messages: - 8377905: gcc.md included with every build Changes: https://git.openjdk.org/jdk/pull/29853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29853&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377905 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29853.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29853/head:pull/29853 PR: https://git.openjdk.org/jdk/pull/29853

5 6