- core-libs-dev - openjdk.org

RFR: 8377983: (zipfs) ZipFileSystem.initCEN needlessly reads END header
by Eirik Bjørsnøs 18 Feb '26

18 Feb '26

Please review this cleanup PR which updates `ZipFileSystem.initCEN` to not include the END header when reading the CEN bytes into memory. The inclusion of the (unused) END header is a remnant from conversion from native to Java in Java 9 and was already fixed for the corresponding `ZipFile.Source.initCEN` via JDK-8339711. Fixing this also in `ZipFileSystem` cleans up the code locally but more importantly brings the implemenation more into alignment with the `ZipFile`. Pure refactoring / cleanup, `noreg-cleanup`. ------------- Commit messages: - Don't include the END header when reading CEN into memory Changes: https://git.openjdk.org/jdk/pull/29741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29741&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377983 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29741.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29741/head:pull/29741 PR: https://git.openjdk.org/jdk/pull/29741

2 3

RFR: 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write() throws NullPointerException if it is already closed
by Jaikiran Pai 18 Feb '26

18 Feb '26

Can I please get a review of this change which proposes to prevent the `NullPointerException` thrown from `com.sun.jndi.ldap.sasl.SaslOutputStream.write()` methods when the stream is already closed? This addresses https://bugs.openjdk.org/browse/JDK-8377486. As noted in that issue, `OutputStream.write(...)` is specified to throw an `IOException` in such cases. The change in this PR updates the `SaslOutputStream.write()` methods to throw an `IOException` when closed. A new test has been introduced to verify this change. ------------- Commit messages: - add a test - 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write() throws NullPointerException if it is already closed Changes: https://git.openjdk.org/jdk/pull/29647/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29647&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377486 Stats: 151 lines in 2 files changed: 145 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29647.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29647/head:pull/29647 PR: https://git.openjdk.org/jdk/pull/29647

2 5

RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch
by David Beaumont 17 Feb '26

17 Feb '26

New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library. Added tests for the error message and other ways in which the jimage file can be corrupt. ------------- Commit messages: - 8372301: Improve error message for jimage command line tool regarding version mismatch Changes: https://git.openjdk.org/jdk/pull/29723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29723&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372301 Stats: 190 lines in 4 files changed: 185 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29723/head:pull/29723 PR: https://git.openjdk.org/jdk/pull/29723

4 10

RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
by Brian Burkhalter 17 Feb '26

17 Feb '26

Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`. ------------- Commit messages: - 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java Changes: https://git.openjdk.org/jdk/pull/29718/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29718&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377910 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29718.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29718/head:pull/29718 PR: https://git.openjdk.org/jdk/pull/29718

2 11

RFR: 8378083: Mark shenandoah/generational/TestOldGrowthTriggers.java as flagless
by SendaoYan 17 Feb '26

17 Feb '26

Hi all, Test test/hotspot/jtreg/gc/shenandoah/generational/TestOldGrowthTriggers.java invoke ProcessTools.createLimitedTestJavaProcessBuilder call the test java process, I think we should mark this test as flagless to avoid duplication run when jtreg received extra jvm options. This PR also remove the uesless 'import jdk.test.lib.Asserts' and fix the typo 'choose' in test/lib/jdk/test/lib/process/ProcessTools.java ------------- Commit messages: - Fix typo choose in test/lib/jdk/test/lib/process/ProcessTools.java - 8378083: Mark shenandoah/generational/TestOldGrowthTriggers.java as flagless Changes: https://git.openjdk.org/jdk/pull/29756/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29756&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378083 Stats: 5 lines in 2 files changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29756/head:pull/29756 PR: https://git.openjdk.org/jdk/pull/29756

1 0

requesting review on JDK-8348828: Windows dll loading now resolves symlinks
by Benjamin Peterson 17 Feb '26

17 Feb '26

I've had a PR for the native library loading code up for a months that I'd appreciate any review on: https://github.com/openjdk/jdk/pull/24694 To summarize the issue and proposed fix: Before OpenJDK 24, System.loadLibrary on Windows passed symbolic links unresolved to the underlying LoadLibrary function. JDK-8003887 caused symbolic links to be resolved by Java before the system LoadLibrary function. Unfortunately, LoadLibrary is clever and may mangle the filename passed to it, which means passing a symlink may not have the same behavior as presenting the fully resolved path. I propose to fix this problem in the PR by disabling LoadLibrary's clever mangling behavior. Thank you for your time, Benjamin

2 5

RFR: 8366736: Closed System.out causes child process to hang on Windows
by Ioi Lam 17 Feb '26

17 Feb '26

The bug is here on line 121: https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f60941… If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f60941… However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. ------------- Commit messages: - 8366736: Closed System.out causes child process to hang on Windows Changes: https://git.openjdk.org/jdk/pull/29198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366736 Stats: 105 lines in 2 files changed: 100 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198 PR: https://git.openjdk.org/jdk/pull/29198

3 22

RFR: 8373661: Add edge case tests for Objects.requireNonNull methods
by eunbin son 16 Feb '26

16 Feb '26

## Summary Adds comprehensive edge case tests for `Objects.requireNonNull`, `requireNonNullElse`, and `requireNonNullElseGet` methods to improve test coverage. ## Problem The current test suite for `Objects.requireNonNull` methods covers basic cases but lacks edge case coverage. ## Solution This PR adds tests for the following edge cases: - requireNonNull with null Supplier parameter - requireNonNull with Supplier that throws exception - requireNonNullElse with both arguments null - requireNonNullElseGet with null supplier - requireNonNullElseGet with supplier returning null ## Issue Fixes JDK-8373661 **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 ## Type of Change - [x] Test addition/modification - [ ] Bug fix - [ ] New feature - [ ] Documentation improvement - [ ] Refactoring ## Testing make test TEST="jtreg:test/jdk/java/util/Objects" ------------- Commit messages: - 8373661: Add edge case tests for Objects.requireNonNull methods Changes: https://git.openjdk.org/jdk/pull/28845/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373661 Stats: 126 lines in 1 file changed: 126 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28845/head:pull/28845 PR: https://git.openjdk.org/jdk/pull/28845

6 28

RFD: A plan to untangle ZipFile.Source.initCEN
by Eirik Bjørsnøs 16 Feb '26

16 Feb '26

Hi, *Summary* Relieve ZipFile.Source.initCEN from non-parsing related responsibilities, such that it can become a pure function for parsing and validating CEN directories. Make it return Source, such that instance fields of this class may become final, immutable and accessible without synchronization. *Motivation* The method ZipFile.Source.initCEN has been the cause of a good amount of head-scratching over the years. It was brought over from the native implementation when this was transitioned to Java in Java 9. Risk assessments at that time probably constrained the code to closely align with the native code, which together with interpreter-friendliness in early startup have affected the current shape of this code. It is hard to summarize the responsibilities of this method, but I'll try: o Call findEND() to read metadata from the (Zip64) END headers in the ZIP file, validate fields and reject invalid values o Determine the position of the first LOC header o Read the CEN byte array from the ZIP file o Construct hash table data structures o Assign these to instance fields in Source o Parse and validate the CEN structure and populate hash table structures o Detect manifest file(s), signature related files and multi-release JAR versions o Detect when a ZIP has more CEN entries than declared by the END header and restart parsing by invoking itself recursively after counting the actual number of CEN entries o Detect when it is being invoked recursively to avoid reading the END and CEN headers twice It's been obvious for a while that this method performs an excessive number of unrelated tasks, knows too much about the state of the object being constructed and handles a disproportionate amount of funky control flow. It calls out to a number of helper methods to perform parsing and validation, some of them static, some relying on instance state. The amount of synchronization in ZipFile today is probably excessive for the current implementation. It made more sense back when ZipFile was backed by native code and resources. In particular, lookup misses pay a high relative cost to synchronization which is probably not needed. Making Source fields final moves us in a direction which may allow us to eventually remove synchronization for operations that only touch a parsed, immutable CEN. *Ideas and plan for improvements* I think we can improve the current situation by: o Moving END header parsing and validation out of initCEN o Moving CEN byte array reading out of initCEN o Making all helper methods static (it's a mix today) At this point, initCEN will almost, but not quite be a pure function for parsing the CEN byte array. So the next natural step is to actually make it a pure function by: o Making it static o Having it return a Source instance instead of assigning to the instance being constructed o Making Source (mostly) immutable by marking parsed instance fields as 'final' Rather than a big bang change, I see this effort as a step-by-step refactoring, probably over several PRs, each focusing on a smaller aspect of refactoring, hopefully making them easier to review. This is not an all-or-nothing effort, most of these changes will be incremental improvements on their own merit. If we don't get all the way, that's also okay. *Feedback?* Input to this idea/plan is welcome. If someone sees reasons this may not be a good idea, it's better to raise such concern here and now. Eirik.

2 5

RFR: 8377978: Add ZipFile test for skipping unrelated ENDSIG found in padded bytes
by Eirik Bjørsnøs 16 Feb '26

16 Feb '26

Please review this test-only PR which introduces a test for an edge case in `ZipFile.Source.findEND`. ZIP files may some times have bytes padded to them after the fixed-size END header. This may be bytes of the comment or just unrelated bytes. Because of this ,`ZipFile.Source.findEnd()` parses the ZIP file in a "backwards" manner, looking for ENDSIG sequences indicating that a candidate END header is found. If the position of the candidate END header and its declared comment length do not match up with the actual ZIP file length, this indicates padded bytes. In this case, `findEND()` will sanity check that the candidate END header points to LOCOFF and CENOFF positions which actually have the expected LOCSIG and CENSIG bytes. The case where a candidate END header is valid but has 'unexpected' bytes padded after it is currently tested by `ReadZip::bytesPaddedAtEnd`. However, there is no current testing for the case where an unrelated `ENDSIG` byte sequence is present in the padded bytes and the sanity check of the LOCOFF and CENOFF contents fails. This is edge case is propably rare in the real world, but it would still be nice to have an automated test of this scenario. ------------- Commit messages: - Update copyright year - Add test for skipping unrelated ENDSIG bytes while looking for the "real" END header Changes: https://git.openjdk.org/jdk/pull/29740/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29740&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377978 Stats: 33 lines in 1 file changed: 32 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29740/head:pull/29740 PR: https://git.openjdk.org/jdk/pull/29740

1 0