- core-libs-dev - openjdk.org

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

RFR: 8377897: jpackage: make jdk.jpackage.internal.MockUtils available from other packages
by Alexey Semenyuk 23 Feb '26

23 Feb '26

- Move jdk.jpackage.internal.MockUtils to jdk.jpackage.test.stdmock.JPackageMockUtils - Make ObjectFactory, ExecutorFactory, RetryExecutorFactory, and Executor accessible for creating jpackage mocks in tests outside the jdk.jpackage.internal package ------------- Commit messages: - Make ObjectFactory, ExecutorFactory, RetryExecutorFactory, and Executor accessible for creating jpackage mocks in tests outside the jdk.jpackage.internal package. Relocate MockUtils from jdk.jpackage.internal to jdk.jpackage.test.stdmock.JPackageMockUtils. The jdk.jpackage.test.stdmock package will contain jpackage-specific mock implementations. - DefaultBundlingEnvironment: move CachingSupplier to the utils package and fix a race condition (with AtomicReference it allowed calling the supplier twice) Changes: https://git.openjdk.org/jdk/pull/29536/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29536&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377897 Stats: 786 lines in 20 files changed: 467 ins; 266 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/29536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29536/head:pull/29536 PR: https://git.openjdk.org/jdk/pull/29536

2 2

RE: macOS: pkg signing full chain workflow
by Florent MARTIN 23 Feb '26

23 Feb '26

Hello, For an application, I need to create a pkg for macOS of a Java application, but jpackage does not provide support for all the steps required. As a reminder, here is the full workflow needed to create a valid pkg that passes Gatekeeper on macOS, which requires three different certificates: * A standard signing certificate * An Apple Developer ID Application certificate * An Apple Developer ID Installer certificate The full workflow is: 1. Signing the native libraries inside the JAR (requires a Developer ID Application certificate) * Basically, this involves extracting the JAR, signing all .jnilib and .dylib files, and rebuilding the JAR. 2. Signing the JAR itself (requires a standard certificate) * Using jarsigner to pass the JVM security check. 3. Generating an application image (.app) 4. Signing the native libraries included in the image (requires a Developer ID Application certificate) 5. Signing the main executable of the image (requires a Developer ID Application certificate) 6. Signing the main bundle of the image (requires a Developer ID Application certificate) 7. (Optional) Adding an entitlements.plist file to allow JNI usage * Needed if using restricted features such as JNI. 8. Creating the installer package (.pkg) 9. Signing the installer package (requires a Developer ID Installer certificate) 10. Notarizing the package (submission to Apple for verification) 11. Stapling the package (embedding the notarization directly into the package) If we skip steps 1 and 2 for preparing the JAR (it would be better if jpackage could handle this automatically), as well as steps 10 and 11, then for steps 3 to 9 we need to use two different certificates, but jpackage provides only a single `--mac-sign` parameter, which does not support multiple certificates and would ideally be split into separate parameters for the application certificate and the installer certificate; as a result, when creating a pkg with jpackage, the App Image inside remains unsigned, which causes Gatekeeper to block the application. Best regards, Florent MARTIN Développeur Cegid Relations Bancaires +33 (0)2 99 55 33 22 flmartin(a)cegid.com<mailto:flmartin@cegid.com> [Facebook]<https://www.facebook.com/CegidGroup/> [Twitter] <https://twitter.com/CegidGroup> [LinkedIn] <https://fr.linkedin.com/company/cegid> cegid.com<https://www.cegid.com/> [Cegid]<http://www.cegid.com/> Cegid est susceptible d'effectuer un traitement sur vos données personnelles à des fins de gestion de notre relation commerciale. Pour plus d'information, consultez https://www.cegid.com/fr/privacy-policy Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de ses destinataires. Toute utilisation ou diffusion, même partielle, non autorisée est interdite. Tout message électronique est susceptible d'altération; Cegid décline donc toute responsabilité au titre de ce message. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'avertir l'expéditeur. Cegid may process your personal data for the purpose of our business relationship management. For more information, please visit our website https://www.cegid.com/en/privacy-policy This message and any attachments are confidential and intended solely for the addressees. Any unauthorized use or disclosure, either whole or partial is prohibited. E-mails are susceptible to alteration; Cegid shall therefore not be liable for the content of this message. If you are not the intended recipient of this message, please delete it and notify the sender.

2 1

RFR: 8160821: VarHandle accesses are penalized when argument conversion is required
by Chen Liang 21 Feb '26

21 Feb '26

Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) ------------- Commit messages: - 8160821 Changes: https://git.openjdk.org/jdk/pull/28585/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8160821 Stats: 135 lines in 7 files changed: 104 ins; 20 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585

10 73

RFR: 8376406: Avoid loading ArrayDeque in jdk.internal.loader.NativeLibraries
by Eirik Bjørsnøs 21 Feb '26

21 Feb '26

Please review this PR which replaces `ArrayDeque` with `ArrayList` for the native library context stack in `jdk.internal.loader.NativeLibraries.NativeLibraryContext`. With this follow-up to similar changes in #29288 and #29430, a simple JAR-based "hello world" program no longer loads the `ArrayDeque` class during startup. The change here is mostly a straightforward replacement. The existing processing was a FIFO stack, which it still is after this PR, just backed by ArrayList instead. Since ArrayList is null-friendly, I added an explicit `Objects.requireNullNull` before pushing to the stack. Pure refactoring, no tests updated, `noreg-cleanup`. ------------- Commit messages: - Replace ArrayDeque with ArrayList in NativeLibraries.NativeLibraryContext Changes: https://git.openjdk.org/jdk/pull/29432/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29432&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376406 Stats: 14 lines in 1 file changed: 3 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29432.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29432/head:pull/29432 PR: https://git.openjdk.org/jdk/pull/29432

3 7

RFR: 8377388: Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner
by Markus KARG 21 Feb '26

21 Feb '26

This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'. ------------- Commit messages: - 8377388: Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner Changes: https://git.openjdk.org/jdk/pull/29627/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29627&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377388 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29627/head:pull/29627 PR: https://git.openjdk.org/jdk/pull/29627

6 12

RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance
by Shaojin Wen 20 Feb '26

20 Feb '26

This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. Parsing scenarios show improvements from 12% to 95% ------------- Commit messages: - bug fix, form @liach - use EnumMap - add benchmark Changes: https://git.openjdk.org/jdk/pull/28471/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372460 Stats: 153 lines in 5 files changed: 149 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471 PR: https://git.openjdk.org/jdk/pull/28471

6 33