From alanb at openjdk.org Fri Aug 1 12:35:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Aug 2025 12:35:00 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test comments [v4] In-Reply-To: References:

Message-ID: <9vgJjBF08ScDCdTq96bI8qdOhE7yoAJoNKj1RiC2UVs=.6558431e-7d89-444b-b4b2-59a05ca8aa60@github.com> On Thu, 31 Jul 2025 16:17:55 GMT, Alan Bateman wrote: >> Brett Okken has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace > > [JDK-8364345](https://bugs.openjdk.org/browse/JDK-8364345) tracks an intermittent failure with the test where CharBufferAsCharSequenceTest.randomizeRange fails. > @AlanBateman [JDK-8364345](https://bugs.openjdk.org/browse/JDK-8364345) was fixed in [5ec88b8](https://github.com/openjdk/jdk/commit/5ec88b87cf525d5ac19147b28e98f225f9f67deb) > > The problem was when a `CharBuffer` which had already had a random range applied was sliced and then randomized again. Good, it means we can close the other issue once the test update goes in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26512#issuecomment-3144428710 From duke at openjdk.org Fri Aug 1 13:40:01 2025 From: duke at openjdk.org (Brett Okken) Date: Fri, 1 Aug 2025 13:40:01 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test comments [v4] In-Reply-To: References:

Message-ID: On Tue, 29 Jul 2025 15:49:33 GMT, Alan Bateman wrote: >> Brett Okken has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace > > test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 104: > >> 102: *

String - description of the test scenario

>> 103: * >> 104: */ > > That helps a bit but I think we need to break up charBufferArguments into simpler/maintainable methods that have clear comments to document the test cases that they generate. Right now it's just way too hard to see what is tested and not tested. @AlanBateman @RogerRiggs any thoughts on just keeping the "random" tests and removing the "static"? As I started breaking the static tests up into simpler methods, they ended up looking like the "random" tests, just with fixed offsets instead of what `randomizeRange` is doing, which did not really seem all that valuable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26512#discussion_r2248015202 From rriggs at openjdk.org Fri Aug 1 14:05:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Aug 2025 14:05:56 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test comments [v4] In-Reply-To: References:

Message-ID: On Wed, 30 Jul 2025 18:03:10 GMT, Brett Okken wrote: >> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282. >> >> Update/clarify test summary tag >> Document the values generated for arguments >> Move the endian-ness qualifier in the test descriptor string to not be first >> Change test method names to more closely match arg names of method under test > > Brett Okken has updated the pull request incrementally with one additional commit since the last revision: > > whitespace I updated the issue title (8364213) to match the current test name; please update the PR description. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26512#issuecomment-3144701811 From rriggs at openjdk.org Fri Aug 1 14:16:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Aug 2025 14:16:55 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test comments [v4] In-Reply-To: References:

Message-ID: <-wZ_04zmIGii_Aabj7TMpeICmz0cLBbvqOC0eofKeuI=.202dfa03-0f3c-4445-8051-c1eb74ee8a7e@github.com> On Fri, 1 Aug 2025 13:37:29 GMT, Brett Okken wrote: >> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 104: >> >>> 102: *

String - description of the test scenario

>>> 103: * >>> 104: */ >> >> That helps a bit but I think we need to break up charBufferArguments into simpler/maintainable methods that have clear comments to document the test cases that they generate. Right now it's just way too hard to see what is tested and not tested. > > @AlanBateman @RogerRiggs any thoughts on just keeping the "random" tests and removing the "static"? > > As I started breaking the static tests up into simpler methods, they ended up looking like the "random" tests, just with fixed offsets instead of what `randomizeRange` is doing, which did not really seem all that valuable. If they duplicate the random tests, then can be removed. Which cases would you remove? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26512#discussion_r2248098512 From duke at openjdk.org Fri Aug 1 15:08:56 2025 From: duke at openjdk.org (Brett Okken) Date: Fri, 1 Aug 2025 15:08:56 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/CharBufferAsCharSequenceTest test comments [v4] In-Reply-To: <-wZ_04zmIGii_Aabj7TMpeICmz0cLBbvqOC0eofKeuI=.202dfa03-0f3c-4445-8051-c1eb74ee8a7e@github.com> References:

<-wZ_04zmIGii_Aabj7TMpeICmz0cLBbvqOC0eofKeuI=.202dfa03-0f3c-4445-8051-c1eb74ee8a7e@github.com> Message-ID: <4bLBYwqOHTgs-zkSj3J-Lsmqugt-xnqQJn-WAoCN5n8=.cd2954d3-0140-4099-b0c5-8eb79ee2f85a@github.com> On Fri, 1 Aug 2025 14:14:47 GMT, Roger Riggs wrote: > Which cases would you remove? All of these: https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java#L108-L182 As I walked through documenting what they cover, and then worked on breaking them out into smaller methods, they are just exercising the different types, at different ranges and offsets. I do not see a single scenario the static tests are covering which the dynamic/random tests do not. There are actually more combos covered with the random tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26512#discussion_r2248217647 From rriggs at openjdk.org Fri Aug 1 15:20:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Aug 2025 15:20:55 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/CharBufferAsCharSequenceTest test comments [v4] In-Reply-To: <4bLBYwqOHTgs-zkSj3J-Lsmqugt-xnqQJn-WAoCN5n8=.cd2954d3-0140-4099-b0c5-8eb79ee2f85a@github.com> References:

<-wZ_04zmIGii_Aabj7TMpeICmz0cLBbvqOC0eofKeuI=.202dfa03-0f3c-4445-8051-c1eb74ee8a7e@github.com> <4bLBYwqOHTgs-zkSj3J-Lsmqugt-xnqQJn-WAoCN5n8=.cd2954d3-0140-4099-b0c5-8eb79ee2f85a@github.com> <40gl3gSIegSMi9AdkQVUViwy4SpxY0Rdun3Ub2J5pQo=.21db223e-0010-4634-8472-461c948564e4@github.com> Message-ID: <0ZC-5Q81Yj5kNCaomgrw7cTSZwdAPxSY8KiviWcQSuo=.90d3810b-0afc-4c97-bb08-db9cde983f0f@github.com> On Fri, 1 Aug 2025 15:18:06 GMT, Roger Riggs wrote: >>> Which cases would you remove? >> >> All of these: >> https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java#L108-L182 >> >> As I walked through documenting what they cover, and then worked on breaking them out into smaller methods, they are just exercising the different types, at different ranges and offsets. I do not see a single scenario the static tests are covering which the dynamic/random tests do not. There are actually more combos covered with the random tests. > > Looks fine to remove those as duplicates. > I do not see a single scenario the static tests are covering which the dynamic/random tests do not. There are actually more combos covered with the random tests. I have observed this situation before elsewhere. Although random tests can be irritating and sometimes tricky to get right, I think in the end the coverage is better. And with the `RandomFactory` seed available, the results are reproducible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26512#discussion_r2248410226 From bpb at openjdk.org Mon Aug 4 21:45:21 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 4 Aug 2025 21:45:21 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed Message-ID: Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. ------------- Commit messages: - 8364277: Add sub-test to existing test - 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed Changes: https://git.openjdk.org/jdk/pull/26631/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364277 Stats: 218 lines in 4 files changed: 206 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/26631.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26631/head:pull/26631 PR: https://git.openjdk.org/jdk/pull/26631 From bpb at openjdk.org Mon Aug 4 21:54:03 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 4 Aug 2025 21:54:03 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/CharBufferAsCharSequenceTest test comments [v5] In-Reply-To: <9_5FaV4QTFnERfhlbO4T1ALBLBLS2XnzfEFIakiMdJM=.18e999fa-2772-4c8b-9249-ee4241141cf4@github.com> References: <9_5FaV4QTFnERfhlbO4T1ALBLBLS2XnzfEFIakiMdJM=.18e999fa-2772-4c8b-9249-ee4241141cf4@github.com> Message-ID: On Fri, 1 Aug 2025 16:28:11 GMT, Brett Okken wrote: >> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282. >> >> Update/clarify test summary tag >> Document the values generated for arguments >> Move the endian-ness qualifier in the test descriptor string to not be first >> Change test method names to more closely match arg names of method under test > > Brett Okken has updated the pull request incrementally with one additional commit since the last revision: > > remove static test cases Looks all right. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26512#pullrequestreview-3085864666 From alanb at openjdk.org Tue Aug 5 06:56:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Aug 2025 06:56:10 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:38:34 GMT, Brian Burkhalter wrote: > Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. On the surface, treating a NTFS directory junction as "other" make sense as they don't fit the file kinds known to the platform. The only reparse points that the JDK can sensibly deal with are symbolic links and Unix domain socket files. My main concern is what might be depending on existing behavior and what inconsistencies will surface if we change this. Would it be possible to enumerate how some of the APIs behave before+after this change? I'm specifically wondering about toRealPath and Files.list/walk behave now and how they will behave with the change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26631#issuecomment-3153735203 From vyazici at openjdk.org Tue Aug 5 08:37:57 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 5 Aug 2025 08:37:57 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character Message-ID: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders. ------------- Commit messages: - Add test to verify `CodingErrorAction.REPLACE` for all charsets - Fix incorrect `HKSCS::repl` override Changes: https://git.openjdk.org/jdk/pull/26635/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26635&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364365 Stats: 483 lines in 3 files changed: 472 ins; 9 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26635.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26635/head:pull/26635 PR: https://git.openjdk.org/jdk/pull/26635 From vyazici at openjdk.org Tue Aug 5 08:38:02 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 5 Aug 2025 08:38:02 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character In-Reply-To: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com> References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com> Message-ID: On Tue, 5 Aug 2025 08:17:40 GMT, Volkan Yazici wrote: > Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders. test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 1: > 1: /* Without the `HKSCS` fix, this test fails for following charsets: Big5-HKSCS x-Big5-HKSCS-2001 x-MS950-HKSCS x-MS950-HKSCS-XP test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 139: > 137: return coderResult.isUnmappable(); > 138: }; > 139: } I'd appreciate it if you can double-check these _"Is the given `char[]` unmappable for a particular encoder?"_ test generators. test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 145: > 143: * different from the given unmappable and the default one. > 144: */ > 145: static byte[] findCustomReplacement(CharsetEncoder encoder, byte[] unmappable) { I'd appreciate it if you can double-check this method. test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 50: > 48: * @build TestEncoderReplaceLatin1 > 49: * @run junit/timeout=10 TestEncoderReplaceUTF16 > 50: * @run junit/timeout=10/othervm -XX:-CompactStrings TestEncoderReplaceUTF16 1. Exercising both compact and inflated layouts for UTF-16. 2. Timeouts ensure that if the `CHARSETS_WITHOUT_UNMAPPABLE` fast-path in `findUnmappableNonLatin1()` becomes ineffective, we will get to know test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 140: > 138: * Finds an {@linkplain CoderResult#isUnmappable() unmappable} non-Latin-1 {@code char[]} for the given encoder. > 139: */ > 140: private static char[] findUnmappableNonLatin1(CharsetEncoder encoder) { I'd appreciate it if you can double-check this method. test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 146: > 144: System.err.println("Character set is known to be absent of unmappable non-Latin-1 characters!"); > 145: return null; > 146: } Without this fast-path, this test take several minutes to complete due to `findUnmappableNonLatin1()` taking ~20 seconds for each character set absent of unmappable Latin-1 characters. test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 184: > 182: } > 183: return sa; > 184: } Used `JavaLangAccess::uncheckedPutCharUTF16` to, given a `char[]`, extract the `byte[]` backing the associated `String`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253526576 PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253550878 PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253554481 PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253532986 PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253556174 PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253530248 PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253542908 From pminborg at openjdk.org Tue Aug 5 09:08:47 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 5 Aug 2025 09:08:47 GMT Subject: RFR: 8359119: Change Charset to use StableValue [v3] In-Reply-To: References: Message-ID: <_slUSdx6gVElcqEg71xpeHsa99DhZ3YteV84gZvR5Hc=.73afbad1-6ba8-487b-ac44-b6cc09fdafc7@github.com> > Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`. > > This PR passes tier1, tier2, and tier3 tests on multiple platforms. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Address comments in PR - Merge branch 'master' into stablify-charset - Revert for loop - Revert more - Revert changes - Add stable value functionality ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25727/files - new: https://git.openjdk.org/jdk/pull/25727/files/21a43faa..728b190f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25727&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25727&range=01-02 Stats: 98272 lines in 2418 files changed: 56523 ins; 27371 del; 14378 mod Patch: https://git.openjdk.org/jdk/pull/25727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25727/head:pull/25727 PR: https://git.openjdk.org/jdk/pull/25727 From pminborg at openjdk.org Tue Aug 5 09:32:05 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 5 Aug 2025 09:32:05 GMT Subject: RFR: 8359119: Change Charset to use StableValue [v2] In-Reply-To: <1HAw1r5SQYTZXX2x4yX6se2gllfH4-o_awAHam6ryKY=.c1da7095-c3ac-4dd0-a9af-d7cc29442a03@github.com> References:

<1HAw1r5SQYTZXX2x4yX6se2gllfH4-o_awAHam6ryKY=.c1da7095-c3ac-4dd0-a9af-d7cc29442a03@github.com> Message-ID: On Sun, 20 Jul 2025 22:14:37 GMT, Shaojin Wen wrote: >> Per Minborg has updated the pull request incrementally with three additional commits since the last revision: >> >> - Revert for loop >> - Revert more >> - Revert changes > > After this proposal, the startup will load 9 more classes > > * Java Code > > public class Startup { > public static void main(String[] args) throws Exception { > Thread.sleep(1000); > } > } > > > > ./build/macosx-aarch64-server-release/images/jdk/bin/java -verbose:class Startup > > > By comparing the output before and after this proposal, we can see that 9 more classes are loaded, as follows: > > [info][class,load] java.nio.charset.Charset$2 > [info][class,load] java.lang.StableValue > [info][class,load] java.util.Objects > [info][class,load] jdk.internal.lang.stable.StableSupplier > [info][class,load] jdk.internal.lang.stable.StableValueImpl > [info][class,load] java.nio.charset.Charset$3 > [info][class,load] java.nio.charset.Charset$4 > [info][class,load] java.nio.charset.Charset$5 > [info][class,load] jdk.internal.ref.Cleaner After the most recent updates, here is what I see if I run the `Startup` code by @wenshao (comparing with main line JDK 26): [0.017s][info][class,load] java.lang.ScopedValue source: shared objects file [0.017s][info][class,load] java.lang.ScopedValue$Cache source: shared objects file [0.017s][info][class,load] java.nio.charset.Charset$3 source: shared objects file [0.017s][info][class,load] java.nio.charset.Charset$4 source: shared objects file [0.017s][info][class,load] java.nio.charset.Charset$5 source: shared objects file ------------- PR Comment: https://git.openjdk.org/jdk/pull/25727#issuecomment-3154291506 From alanb at openjdk.org Tue Aug 5 10:14:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Aug 2025 10:14:15 GMT Subject: RFR: 8359119: Change Charset to use StableValue [v3] In-Reply-To: <_slUSdx6gVElcqEg71xpeHsa99DhZ3YteV84gZvR5Hc=.73afbad1-6ba8-487b-ac44-b6cc09fdafc7@github.com> References: <_slUSdx6gVElcqEg71xpeHsa99DhZ3YteV84gZvR5Hc=.73afbad1-6ba8-487b-ac44-b6cc09fdafc7@github.com> Message-ID: On Tue, 5 Aug 2025 09:08:47 GMT, Per Minborg wrote: >> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`. >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Address comments in PR > - Merge branch 'master' into stablify-charset > - Revert for loop > - Revert more > - Revert changes > - Add stable value functionality src/java.base/share/classes/java/nio/charset/Charset.java line 387: > 385: } > 386: > 387: private static final ScopedValue IN_LOOKUP = ScopedValue.newInstance(); Thanks for change this to use ScopedValue. Once we change URL and ZipFile to do the same then it should remove the loading of ThreadTracker from startup to offset the loading of other classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2253875925 From bpb at openjdk.org Tue Aug 5 16:07:02 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 5 Aug 2025 16:07:02 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 06:53:24 GMT, Alan Bateman wrote: > Would it be possible to enumerate how some of the APIs behave before+after this change? I will investigate this. Meanwhile I should note that all `jdk_nio` pass in the CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26631#issuecomment-3155743847 From bpb at openjdk.org Tue Aug 5 17:48:59 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 5 Aug 2025 17:48:59 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References: Message-ID: > Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26631/files - new: https://git.openjdk.org/jdk/pull/26631/files/c5794766..cf9eab46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=00-01 Stats: 12 lines in 3 files changed: 8 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26631.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26631/head:pull/26631 PR: https://git.openjdk.org/jdk/pull/26631 From duke at openjdk.org Tue Aug 5 18:20:04 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Tue, 5 Aug 2025 18:20:04 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 18:17:32 GMT, Johannes D?bler wrote: > Since this logic to load the FileUtils library is now used twice, why not move it into a helper method Sounds like a good idea. I'll investigate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255029517 From duke at openjdk.org Tue Aug 5 18:45:05 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Tue, 5 Aug 2025 18:45:05 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 17:48:59 GMT, Brian Burkhalter wrote: >> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test test/lib/jdk/test/lib/util/FileUtils.java line 449: > 447: > 448: // Create a link from "junction" to the real path of "target" > 449: public static boolean createDirectoryJunction(String junction, String target) Suggestion: Use Path as type for parameters `junction` and `target` to avoid Path|File->String->Path|File conversions (e.g. the only caller Basic.java already has a Path object for parameter junction, why convert to a String just to recreate a File inside `createDirectoryJunction`). test/lib/jdk/test/lib/util/FileUtils.java line 463: > 461: return createWinDirectoryJunction(junction, target); > 462: } else { > 463: Files.createSymbolicLink(Path.of(junction), Path.of(target)); Suggestion: Junctions are Windows-only, so why not throw a RuntimeException for the non-windows case (and maybe also rename the method to something like `createWindowsDirectoryJunction`) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255068530 PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255040929 From duke at openjdk.org Tue Aug 5 19:31:05 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Tue, 5 Aug 2025 19:31:05 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 18:27:13 GMT, Johannes D?bler wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test > > test/lib/jdk/test/lib/util/FileUtils.java line 463: > >> 461: return createWinDirectoryJunction(junction, target); >> 462: } else { >> 463: Files.createSymbolicLink(Path.of(junction), Path.of(target)); > > Suggestion: Junctions are Windows-only, so why not throw a RuntimeException for the non-windows case (and maybe also rename the method to something like `createWindowsDirectoryJunction`) A `RuntimeException` for non-Windows, i.e., Unix, would be a test failure and we can't have that. I think it would be better to convert the test to JUnit 5 and use [@EnabledOnOs(OS.WINDOWS)](https://docs.junit.org/5.2.0/api/org/junit/jupiter/api/condition/EnabledOnOs.html), but that might not be in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255155387 From duke at openjdk.org Tue Aug 5 19:44:09 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Tue, 5 Aug 2025 19:44:09 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 19:28:25 GMT, Brian Burkhalter wrote: >> test/lib/jdk/test/lib/util/FileUtils.java line 463: >> >>> 461: return createWinDirectoryJunction(junction, target); >>> 462: } else { >>> 463: Files.createSymbolicLink(Path.of(junction), Path.of(target)); >> >> Suggestion: Junctions are Windows-only, so why not throw a RuntimeException for the non-windows case (and maybe also rename the method to something like `createWindowsDirectoryJunction`) > > A `RuntimeException` for non-Windows, i.e., Unix, would be a test failure and we can't have that. I think it would be better to convert the test to JUnit 5 and use [@EnabledOnOs(OS.WINDOWS)](https://docs.junit.org/5.2.0/api/org/junit/jupiter/api/condition/EnabledOnOs.html), but that might not be in this PR. Right, but this method is just a helper method not a test method and the caller, e.g. Basic.attributeReadWriteTests|checkAttributesOfJunction should only call it if on Windows. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255177168 From bpb at openjdk.org Tue Aug 5 19:44:10 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 5 Aug 2025 19:44:10 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 19:38:57 GMT, Johannes D?bler wrote: > Right, but this method is just a helper method Okay, I'll look into this and the other suggestions. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255181551 From bpb at openjdk.org Tue Aug 5 21:10:19 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 5 Aug 2025 21:10:19 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 06:53:24 GMT, Alan Bateman wrote: > I'm specifically wondering about toRealPath and Files.list/walk behave now and how they will behave with the change. For a file tree rooted at dir dir: file1* file2* file3* subdir/ dir/subdir: file4* file5* and a directory junction `junction` whose target is `dir`, then for `p = Path.of("junction")`, the results of `p.toRealPath()`, `p.toRealPath(NOFOLLOW_LINKS)`, `Files.list(p)`, and `Files.walk(p, FOLLOW_LINKS)` are identical before and after this change. Only the results of `Files.walk(p)` differ and are as follows: - **before** ```[junction, junction\file1, junction\file2, junction\file3, junction\subdir, junction\subdir\file4, junction\subdir\file5]``` - **after** ```[junction]```. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26631#issuecomment-3156651833 From sherman at openjdk.org Wed Aug 6 00:29:04 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 6 Aug 2025 00:29:04 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character In-Reply-To: References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com> Message-ID: On Tue, 5 Aug 2025 08:29:21 GMT, Volkan Yazici wrote: >> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders. > > test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 139: > >> 137: return coderResult.isUnmappable(); >> 138: }; >> 139: } > > I'd appreciate it if you can double-check these _"Is the given `char[]` unmappable for a particular encoder?"_ test generators. I might be missing something you're trying to do here, but any reason why we can't just go return c -> !encoder.canEncode(c[0]); as the predicate? I think we are doing 'single char', no surrogates, here, right? or simply do with private static char[] findUnmappable(CharsetEncoder encoder) { for (char c = 0; c < 0xff; c++) { if (!encoder.canEncode(c)) return new char[]{c}; } System.err.println("Could not find an unmappable character!"); return null; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2255587104 From bpb at openjdk.org Wed Aug 6 01:11:48 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 01:11:48 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v3] In-Reply-To: References: Message-ID: > Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8364277: Clean up per reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26631/files - new: https://git.openjdk.org/jdk/pull/26631/files/cf9eab46..ebd6f415 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=01-02 Stats: 34 lines in 3 files changed: 9 ins; 12 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/26631.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26631/head:pull/26631 PR: https://git.openjdk.org/jdk/pull/26631 From bpb at openjdk.org Wed Aug 6 01:14:10 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 01:14:10 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 18:41:44 GMT, Johannes D?bler wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364277: 1) Add and use package scope isDirectoryJunction(); 2) Remove explicit delete of junction from test > > test/lib/jdk/test/lib/util/FileUtils.java line 449: > >> 447: >> 448: // Create a link from "junction" to the real path of "target" >> 449: public static boolean createDirectoryJunction(String junction, String target) > > Suggestion: Use Path as type for parameters `junction` and `target` to avoid Path|File->String->Path|File conversions (e.g. the only caller Basic.java already has a Path object for parameter junction, why convert to a String just to recreate a File inside `createDirectoryJunction`). Done in ebd6f41. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255636088 From bpb at openjdk.org Wed Aug 6 01:14:11 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 01:14:11 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 18:21:12 GMT, Brian Burkhalter wrote: >> test/lib/jdk/test/lib/util/FileUtils.java line 457: >> >>> 455: // Create a directory junction or a symbolic link >>> 456: if (IS_WINDOWS) { >>> 457: if (!nativeLibLoaded) { >> >> Suggestion: Since this logic to load the FileUtils library is now used twice, why not move it into a helper method which might also be synchronized (if tests are executed in parallel). > >> Since this logic to load the FileUtils library is now used twice, why not move it into a helper method > > Sounds like a good idea. I'll investigate. Done in ebd6f41. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255635632 From bpb at openjdk.org Wed Aug 6 01:14:11 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 01:14:11 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 19:41:11 GMT, Brian Burkhalter wrote: >> Right, but this method is just a helper method not a test method and the caller, e.g. Basic.attributeReadWriteTests|checkAttributesOfJunction should only call it if on Windows. > >> Right, but this method is just a helper method > > Okay, I'll look into this and the other suggestions. Thanks. Done in ebd6f41. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255635876 From bpb at openjdk.org Wed Aug 6 01:17:20 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 01:17:20 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Tue, 5 Aug 2025 19:26:36 GMT, Johannes D?bler wrote: > Would it be possible to avoid the dreaded goto I expect so, with some careful editing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255638428 From sherman at openjdk.org Wed Aug 6 01:54:14 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 6 Aug 2025 01:54:14 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character In-Reply-To: References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com> Message-ID: <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com> On Tue, 5 Aug 2025 08:31:31 GMT, Volkan Yazici wrote: >> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders. > > test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 140: > >> 138: * Finds an {@linkplain CoderResult#isUnmappable() unmappable} non-Latin-1 {@code char[]} for the given encoder. >> 139: */ >> 140: private static char[] findUnmappableNonLatin1(CharsetEncoder encoder) { > > I'd appreciate it if you can double-check this method. I would assume your "double char" actually means the "surrogate pair"? I believe for the first pass of scanning you might want to skip the 'surrogate", as a single dangling surrogate char should trigger a "malformed" error, instead of 'unmappable", if the charset is implemented to handle supplementary character. for (char c = 0xFF; c < 0xFFFF; c++) { if (Character.isSurrogate(c)) continue; if (!encoder.canEncode(c)) return new char[]{c}; } And for the second pass for the 'surrogates", I think we can just pick any non-bmp panel, which should always be translated into a surrogate pair and check if the charset can map/encode it, if not, it's our candidate. for (int i = 0x10000; i < 0x1FFFF; i++) { char[] cc = Character.toChars(i); if (!encoder.canEncode(new String(cc))) return cc; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2255682596 From sherman at openjdk.org Wed Aug 6 02:20:03 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 6 Aug 2025 02:20:03 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character In-Reply-To: References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com> Message-ID: On Tue, 5 Aug 2025 08:20:55 GMT, Volkan Yazici wrote: >> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders. > > test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 146: > >> 144: System.err.println("Character set is known to be absent of unmappable non-Latin-1 characters!"); >> 145: return null; >> 146: } > > Without this fast-path, this test take several minutes to complete due to `findUnmappableNonLatin1()` taking ~20 seconds for each character set absent of unmappable Latin-1 characters. we definitely want to exclude 'some' charsets here. yes, all unicode variants probably should be excluded, as they are expected to have a 'mapping' for every unicode character. Additionally, many charsets have an "internal status", meaning they might shift in and shift out its status based on input. See https://www.rfc-editor.org/rfc/rfc1468.html for an example. The encoder might/should add the shift-in/out escape sequence characters on top of the 'replacement', if the replacement character's target sub-charset does not match the 'existing' sub-charset. i would assume this is really out of the scope of this pr though :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2255705386 From alanb at openjdk.org Wed Aug 6 06:06:04 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Aug 2025 06:06:04 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v3] In-Reply-To: References:

Message-ID: On Wed, 6 Aug 2025 01:11:48 GMT, Brian Burkhalter wrote: >> Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8364277: Clean up per reviewer comments src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 419: > 417: return false; > 418: return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 && > 419: (fileAttrs & FILE_ATTRIBUTE_REPARSE_POINT) != 0); Should this just check if reparseTag has the value IO_REPARSE_TAG_MOUNT_POINT? src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 436: > 434: if (isSymbolicLink()) > 435: return false; > 436: return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 && I assume it means that isDirectory no longer needs to use isSymbolicLink as the change means it will return false for all files that are reparse points. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255946387 PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2255949663 From vyazici at openjdk.org Wed Aug 6 10:01:13 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 6 Aug 2025 10:01:13 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character In-Reply-To: References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>

Message-ID: On Wed, 6 Aug 2025 02:17:15 GMT, Xueming Shen wrote: > if the replacement character's target sub-charset does not match the 'existing' sub-charset In such a `replacement`, does `CharsetEncoder::isLegalReplacement` still return `true`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2256646879 From vyazici at openjdk.org Wed Aug 6 10:55:02 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 6 Aug 2025 10:55:02 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character In-Reply-To: <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com> References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com> <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com> Message-ID: On Wed, 6 Aug 2025 01:51:54 GMT, Xueming Shen wrote: > for (char c = 0xFF; c < 0xFFFF; c++) Doesn't this exclude `0xFFFF`, which is a valid (single-`char`, non-surrogate) BMP character? > ... we can just pick any non-bmp panel ... > ``` > for (int i = 0x10000; i < 0x1FFFF; i++) { ... > ``` Doesn't the non-BMP range rather end with 0x10FFFF? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2256774007 From duke at openjdk.org Wed Aug 6 14:07:22 2025 From: duke at openjdk.org (duke) Date: Wed, 6 Aug 2025 14:07:22 GMT Subject: Withdrawn: 8353923: (fs) Further improve performance of URI -> Path conversion (win) In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 23:48:18 GMT, Brian Burkhalter wrote: > If the path portion of a `URI` permits, then simply replace all `'\'` with `'/'` instead of completely parsing the path. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24638 From bpb at openjdk.org Wed Aug 6 17:39:25 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 17:39:25 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v4] In-Reply-To: References: Message-ID: <-brKvHWh2bXqcbEOObF6pI7lZaS6P19CnWXppe4xt84=.4627fb30-7a31-45ed-b04e-a72fb2d2c7d0@github.com> > Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8364277: 1) improve isDirectory[Junction] per Reviewer comments; 2) restructure native test code to remove the dreaded gotos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26631/files - new: https://git.openjdk.org/jdk/pull/26631/files/ebd6f415..481bdbcc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=02-03 Stats: 100 lines in 3 files changed: 31 ins; 35 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/26631.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26631/head:pull/26631 PR: https://git.openjdk.org/jdk/pull/26631 From bpb at openjdk.org Wed Aug 6 17:39:27 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 17:39:27 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v3] In-Reply-To: References:

Message-ID: <0C-F2471I42736TtBGckvNQ_C6pv3urTQTLQ-4zcIbk=.8ff4af39-4d0d-41c5-8cb2-b857f9a98d3c@github.com> On Wed, 6 Aug 2025 06:01:07 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364277: Clean up per reviewer comments > > src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 419: > >> 417: return false; >> 418: return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 && >> 419: (fileAttrs & FILE_ATTRIBUTE_REPARSE_POINT) != 0); > > Should this just check if reparseTag has the value IO_REPARSE_TAG_MOUNT_POINT? So changed in 481bdbc. > src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 436: > >> 434: if (isSymbolicLink()) >> 435: return false; >> 436: return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 && > > I assume it means that isDirectory no longer needs to use isSymbolicLink as the change means it will return false for all files that are reparse points. So changed in 481bdbc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2257849276 PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2257849755 From bpb at openjdk.org Wed Aug 6 17:39:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 17:39:28 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v2] In-Reply-To: References:

Message-ID: On Wed, 6 Aug 2025 01:14:15 GMT, Brian Burkhalter wrote: >> test/lib/jdk/test/lib/util/libFileUtils.c line 167: >> >>> 165: lpInBuffer = NULL; >>> 166: >>> 167: if (result == 0) { >> >> Suggestion: Would it be possible to avoid the dreaded goto >> >> if ((result != 0) && (CloseHandle(hJunction) != 0)) { >> return JNI_TRUE; >> } >> ...do error handling... > >> Would it be possible to avoid the dreaded goto > > I expect so, with some careful editing. `goto`s removed in 481bdbc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2257848055 From cushon at openjdk.org Wed Aug 6 17:49:26 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 6 Aug 2025 17:49:26 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v7] In-Reply-To: References:

Message-ID: On Thu, 17 Jul 2025 15:23:10 GMT, Liam Miller-Cushon wrote: >> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: >> >> - add @Override for clean() method >> - more commentary for reserveMemory > > src/java.base/share/classes/java/nio/BufferCleaner.java line 203: > >> 201: } >> 202: >> 203: private static final class CleaningThread extends Thread { > > Similar to https://bugs.openjdk.org/browse/JDK-8346124, should this be creating an `InnocuousThread`? I filed https://bugs.openjdk.org/browse/JDK-8364954 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2257877328 From sherman at openjdk.org Wed Aug 6 18:04:28 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 6 Aug 2025 18:04:28 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character In-Reply-To: References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com> <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com> Message-ID: On Wed, 6 Aug 2025 10:52:00 GMT, Volkan Yazici wrote: >> I would assume your "double char" actually means the "surrogate pair"? >> >> I believe for the first pass of scanning you might want to skip the 'surrogate", as a single dangling surrogate char should trigger a "malformed" error, instead of 'unmappable", if the charset is implemented to handle supplementary character. >> >> for (char c = 0xFF; c < 0xFFFF; c++) { >> if (Character.isSurrogate(c)) >> continue; >> if (!encoder.canEncode(c)) >> return new char[]{c}; >> } >> >> And for the second pass for the 'surrogates", I think we can just pick any non-bmp panel, which should always be translated into a surrogate pair and check if the charset can map/encode it, if not, it's our candidate. >> >> for (int i = 0x10000; i < 0x1FFFF; i++) { >> char[] cc = Character.toChars(i); >> if (!encoder.canEncode(new String(cc))) >> return cc; >> } > >> for (char c = 0xFF; c < 0xFFFF; c++) > > Doesn't this exclude `0xFFFF`, which is a valid (single-`char`, non-surrogate) BMP character? > >> ... we can just pick any non-bmp panel ... >> ``` >> for (int i = 0x10000; i < 0x1FFFF; i++) { ... >> ``` > > Doesn't the non-BMP range rather end with 0x10FFFF? (1) we might want to include 0xffff in first pass (2) we just need to pick any unmappable non-bmp character, i would assume that it should be pretty safe we will find one in the first non-bmp panel that is not encoded by a specific charset. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2257902674 From alanb at openjdk.org Wed Aug 6 18:32:17 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Aug 2025 18:32:17 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v3] In-Reply-To: <0C-F2471I42736TtBGckvNQ_C6pv3urTQTLQ-4zcIbk=.8ff4af39-4d0d-41c5-8cb2-b857f9a98d3c@github.com> References:

<0C-F2471I42736TtBGckvNQ_C6pv3urTQTLQ-4zcIbk=.8ff4af39-4d0d-41c5-8cb2-b857f9a98d3c@github.com> Message-ID: <58J2J4rqzVd5wTpMm7cf16SuQBGu0AtSoTRzoOMdyo0=.551b985d-5ef3-4945-85dd-9660103f90a1@github.com> On Wed, 6 Aug 2025 17:34:13 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 419: >> >>> 417: return false; >>> 418: return ((fileAttrs & FILE_ATTRIBUTE_DIRECTORY) != 0 && >>> 419: (fileAttrs & FILE_ATTRIBUTE_REPARSE_POINT) != 0); >> >> Should this just check if reparseTag has the value IO_REPARSE_TAG_MOUNT_POINT? > > So changed in 481bdbc. Thanks for these updates, the src changes look good now. I haven't looked at the test updates yet, will try to get to this soon. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26631#discussion_r2257960839 From sherman at openjdk.org Wed Aug 6 18:35:16 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 6 Aug 2025 18:35:16 GMT Subject: RFR: 8364365: HKSCS encoder does not properly set the replacement character In-Reply-To: References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>

Message-ID: On Wed, 6 Aug 2025 09:58:16 GMT, Volkan Yazici wrote: >> we definitely want to exclude 'some' charsets here. yes, all unicode variants probably should be excluded, as they are expected to have a 'mapping' for every unicode character. Additionally, many charsets have an "internal status", meaning they might shift in and shift out its status based on input. See https://www.rfc-editor.org/rfc/rfc1468.html for an example. The encoder might/should add the shift-in/out escape sequence characters on top of the 'replacement', if the replacement character's target sub-charset does not match the 'existing' sub-charset. i would assume this is really out of the scope of this pr though :-) > >> if the replacement character's target sub-charset does not match the 'existing' sub-charset > > In such a `replacement`, does `CharsetEncoder::isLegalReplacement` still return `true`? it's 'tricky' :-) some charsets have a default initial status, ascii-charset for example, this might trigger false return if the replacement is set without the appropriate shift-in/out esc-seq when target-sub-charset and existing charset are not matched. I'm not confident that all our implementations really handle it correctly :-) it might be interested (not really :-) given these charsets might not be that important these days and it's rare people try to change the default replacement bytes) to do full-scan-check, but again probably is not in-scope of this change. iso2022-jp is one such charset. we attempt to shift-in to the correct sub-charset by keeping the requested mode in **_implReplaceWith_** protected void implReplaceWith(byte[] newReplacement) { /* It's almost impossible to decide which charset they belong to. The best thing we can do here is to "guess" based on the length of newReplacement. */ if (newReplacement.length == 1) { replaceMode = ASCII; } else if (newReplacement.length == 2) { replaceMode = JISX0208_1983; } } then during encoding if (unmappableCharacterAction() == CodingErrorAction.REPLACE && currentMode != replaceMode) { if (dl - dp < 3) return CoderResult.OVERFLOW; if (replaceMode == ASCII) { da[dp++] = (byte)0x1b; da[dp++] = (byte)0x28; da[dp++] = (byte)0x42; } else { da[dp++] = (byte)0x1b; da[dp++] = (byte)0x24; da[dp++] = (byte)0x42; } currentMode = replaceMode; } i believe this might not be really bulletproved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2257966394 From bpb at openjdk.org Wed Aug 6 19:59:53 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Aug 2025 19:59:53 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v5] In-Reply-To: References: Message-ID: <0_fTcRHQzc6aQs3Y_9iO__ygAcdP97VNH3eOVCMi_V8=.26d9cdbf-9fa5-487a-85de-03a15742d202@github.com> > Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8364277: Ignore restricted warning building BUILD_TEST_LIB_JAR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26631/files - new: https://git.openjdk.org/jdk/pull/26631/files/481bdbcc..60f5315b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26631.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26631/head:pull/26631 PR: https://git.openjdk.org/jdk/pull/26631 From rriggs at openjdk.org Wed Aug 6 20:18:26 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Aug 2025 20:18:26 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/CharBufferAsCharSequenceTest test comments [v5] In-Reply-To: <9_5FaV4QTFnERfhlbO4T1ALBLBLS2XnzfEFIakiMdJM=.18e999fa-2772-4c8b-9249-ee4241141cf4@github.com> References: <9_5FaV4QTFnERfhlbO4T1ALBLBLS2XnzfEFIakiMdJM=.18e999fa-2772-4c8b-9249-ee4241141cf4@github.com> Message-ID: On Fri, 1 Aug 2025 16:28:11 GMT, Brett Okken wrote: >> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282. >> >> Update/clarify test summary tag >> Document the values generated for arguments >> Move the endian-ness qualifier in the test descriptor string to not be first >> Change test method names to more closely match arg names of method under test > > Brett Okken has updated the pull request incrementally with one additional commit since the last revision: > > remove static test cases Looks good, thanks for the test improvements. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26512#pullrequestreview-3094103208 From cushon at openjdk.org Wed Aug 6 23:22:24 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 6 Aug 2025 23:22:24 GMT Subject: RFR: 8364954: Migrate CleaningThread in BufferCleaner to InnocuousThread Message-ID: This migrates a `Thread` introduced in [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332) to use `InnocuousThread`, similar to the changes in [JDK-8345432](https://bugs.openjdk.org/browse/JDK-8345432) to migrate other uses of `Thread` in `java.nio` to `InnocuousThread`. ------------- Commit messages: - 8364954: Migrate CleaningThread in BufferCleaner to InnocuousThread Changes: https://git.openjdk.org/jdk/pull/26665/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26665&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364954 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26665.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26665/head:pull/26665 PR: https://git.openjdk.org/jdk/pull/26665 From bpb at openjdk.org Thu Aug 7 00:45:20 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Aug 2025 00:45:20 GMT Subject: RFR: 8364277: (fs) BasicFileAttributes.isDirectory and isOther return true for NTFS directory junctions when links not followed [v6] In-Reply-To: References: Message-ID: > Change `BasicFileAttributes` for Windows such that for a directory junction `isOther` returns `true` but all other `is*` methods return `false`. Without this change, `isDirectory` also returns `true`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8364277: Revert change to BuildTestLib.gmk; move @SuppressWarnings to correct place in FileUtils.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26631/files - new: https://git.openjdk.org/jdk/pull/26631/files/60f5315b..a30e0ce8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26631&range=04-05 Stats: 3 lines in 2 files changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26631.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26631/head:pull/26631 PR: https://git.openjdk.org/jdk/pull/26631 From duke at openjdk.org Thu Aug 7 13:33:16 2025 From: duke at openjdk.org (duke) Date: Thu, 7 Aug 2025 13:33:16 GMT Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/CharBufferAsCharSequenceTest test comments [v5] In-Reply-To: <9_5FaV4QTFnERfhlbO4T1ALBLBLS2XnzfEFIakiMdJM=.18e999fa-2772-4c8b-9249-ee4241141cf4@github.com> References: <9_5FaV4QTFnERfhlbO4T1ALBLBLS2XnzfEFIakiMdJM=.18e999fa-2772-4c8b-9249-ee4241141cf4@github.com> Message-ID: On Fri, 1 Aug 2025 16:28:11 GMT, Brett Okken wrote: >> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282. >> >> Update/clarify test summary tag >> Document the values generated for arguments >> Move the endian-ness qualifier in the test descriptor string to not be first >> Change test method names to more closely match arg names of method under test > > Brett Okken has updated the pull request incrementally with one additional commit since the last revision: > > remove static test cases @bokken Your change (at version 9ecfcb0c9ebb4f76eb58b6a42c7805a7645bb82a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26512#issuecomment-3164219463 From alanb at openjdk.org Thu Aug 7 13:40:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Aug 2025 13:40:15 GMT Subject: RFR: 8364954: Migrate CleaningThread in BufferCleaner to InnocuousThread In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 23:17:27 GMT, Liam Miller-Cushon wrote: > This migrates a `Thread` introduced in [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332) to use `InnocuousThread`, similar to the changes in [JDK-8345432](https://bugs.openjdk.org/browse/JDK-8345432) to migrate other uses of `Thread` in `java.nio` to `InnocuousThread`. Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/nio/BufferCleaner.java line 239: > 237: private static final CleanerList cleanerList = new CleanerList(); > 238: private static final ReferenceQueue