From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth 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 10 additional commits since the last revision: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From lkorinth at openjdk.org Mon Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31: > >> 29: * @compile SuspendResume2.java >> 30: * @run driver jdk.test.lib.FileInstaller . . >> 31: * @run main/othervm/native/timeout=700 > > Why `700` instead of `480` in this file? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). > >> while not multiplying a 10x factor with four resulting in a 40x factor. > > Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From vyazici at openjdk.org Mon Sep 1 16:16:23 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 1 Sep 2025 16:16:23 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v11] In-Reply-To: References: Message-ID: > `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Fix `ClassCastException` spotted by `ReadWriteString` - Merge remote-tracking branch 'upstream/master' into jlaNoRepl - Improve Javadoc of touched `encode*()` methods - Rename `exceptionClass` to `exClass` - Rename `NoReplacement` suffix to `OrThrow` - Simplify `encodeWithEncoder` and trim long lines - Improve docs - Improve "sneaky throws" - Improve comment style - Renamed to `malformedASCII` - ... and 17 more: https://git.openjdk.org/jdk/compare/7f0cd648...a69f9fd3 ------------- Changes: https://git.openjdk.org/jdk/pull/26413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=10 Stats: 462 lines in 8 files changed: 242 ins; 122 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/26413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413 PR: https://git.openjdk.org/jdk/pull/26413 From vyazici at openjdk.org Mon Sep 1 19:08:44 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 1 Sep 2025 19:08:44 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v4] In-Reply-To: <46MfOJA8bICEbZ7EpwzTealkJKqvsxREIKZhsyA-LRE=.295d951f-1eb7-4ad7-9e6a-3f2810c581ce@github.com> References: <46MfOJA8bICEbZ7EpwzTealkJKqvsxREIKZhsyA-LRE=.295d951f-1eb7-4ad7-9e6a-3f2810c581ce@github.com> Message-ID: On Tue, 19 Aug 2025 14:59:04 GMT, Roger Riggs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant type parameters > > It seems that the API is overloaded trying to satisfy too many requirements, replace/noreplace, throw/nothrow and supporting arbitrary Charsets. There are multiple callers that only need to create a string from byte array holding latin1. > They are burdened with catching and ignoring exceptions that do not occur. > > I'm suggesting breaking out that use case in PR#https://github.com/openjdk/jdk/pull/26831. > That leaves `Files.readString` that needs the full CharSet/noReplace/throw behavior. @RogerRiggs, @liach, @AlanBateman, I needed to push a `ClassCastException` fix in a69f9fd, which further simplified the sneaky-throws logic in `String`. Would one of you mind, unless you have objections, re-approving the PR, please? Note that I've attached passing `tier1,2` results to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3243114718 From pminborg at openjdk.org Tue Sep 2 07:21:50 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 2 Sep 2025 07:21:50 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <22V1rYuOtYARMeEUsFkV-SR6ezs4tfvj6K-XE_Lg-qA=.dd66d148-f759-47f3-8e86-f9c45cd43a20@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> <22V1rYuOtYARMeEUsFkV-SR6ezs4tfvj6K-XE_Lg-qA=.dd66d148-f759-47f3-8e86-f9c45cd43a20@github.com> Message-ID: <2lk-MLbIZMKEXquuPPL7mgM4jRjY2rPYdLqP54pTRmE=.ff585c6c-7422-46b6-bc77-c0a2af111301@github.com> On Thu, 28 Aug 2025 15:02:57 GMT, Darragh Clarke wrote: >> Darragh Clarke 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 12 additional commits since the last revision: >> >> - fixed copyright header >> - merged master into branch >> - moved repeating code into own method >> - implementing feedback, adding missing errno checks, cleanup >> - feedback >> - general cleanup >> - small refactoring >> - Performance >> - implementing feedback >> - removed unrelated change >> - ... and 2 more: https://git.openjdk.org/jdk/compare/e5469821...cc5f558a > > Thanks for the thorough review, I'll address all these in the next commit. > As for the changes to generated code, I'll draft up a list of what changed and why, though FFMUtils in particular came about as trying to move reusable utility methods into a shared place to cut down on code duplication going forward > @DarraghClarke @minborg Would it be possible to provide a brief summary on what modifications have been done to the jextract-generated classes? The use of FFMUtils jumps out. Ideally they would be checked in without modification as it makes it easy to re-generate. It might be that this never happens but there is something a bit uncomfortable about checking in modified sources. I think we could document the changes where we document how jextract is run. Ideally, we spoke about `sed` but maybe a more informal description can be made? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3244089693 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From alanb at openjdk.org Tue Sep 2 07:38:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Sep 2025 07:38:44 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <2lk-MLbIZMKEXquuPPL7mgM4jRjY2rPYdLqP54pTRmE=.ff585c6c-7422-46b6-bc77-c0a2af111301@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> <22V1rYuOtYARMeEUsFkV-SR6ezs4tfvj6K-XE_Lg-qA=.dd66d148-f759-47f3-8e86-f9c45cd43a20@github.com> <2lk-MLbIZMKEXquuPPL7mgM4jRjY2rPYdLqP54pTRmE=.ff585c6c-7422-46b6-bc77-c0a2af111301@github.com> Message-ID: On Tue, 2 Sep 2025 07:18:54 GMT, Per Minborg wrote: > I think we could document the changes where we document how jextract is run. Ideally, we spoke about `sed` but maybe a more informal description can be made? That might be okay. In the distant past the in-tree copy of the zlib code needed a few patches. The list of changes, and reasoning, went into a readme file to help future sync ups. It should be very rare that we need to re-run jextract but if we do then it's important to document the patches. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3244146703 From alanb at openjdk.org Tue Sep 2 11:43:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Sep 2025 11:43:48 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v11] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 16:16:23 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Fix `ClassCastException` spotted by `ReadWriteString` > - Merge remote-tracking branch 'upstream/master' into jlaNoRepl > - Improve Javadoc of touched `encode*()` methods > - Rename `exceptionClass` to `exClass` > - Rename `NoReplacement` suffix to `OrThrow` > - Simplify `encodeWithEncoder` and trim long lines > - Improve docs > - Improve "sneaky throws" > - Improve comment style > - Renamed to `malformedASCII` > - ... and 17 more: https://git.openjdk.org/jdk/compare/7f0cd648...a69f9fd3 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3176161682 From vyazici at openjdk.org Tue Sep 2 12:46:02 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 12:46:02 GMT Subject: Integrated: 8356439: Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote: > `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. This pull request has now been integrated. Changeset: eea50fbc Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/eea50fbc1b24710b18eff4b59dc90dee3736cd95 Stats: 462 lines in 8 files changed: 242 ins; 122 del; 98 mod 8356439: Rename JavaLangAccess::*NoRepl methods Reviewed-by: alanb, liach, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/26413 From vyazici at openjdk.org Tue Sep 2 13:17:03 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 13:17:03 GMT Subject: RFR: 8356439: Backout recent JavaLangAccess changes breaking the build Message-ID: Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. ------------- Commit messages: - Revert "8356439: Rename JavaLangAccess::*NoRepl methods" Changes: https://git.openjdk.org/jdk/pull/27050/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356439 Stats: 462 lines in 8 files changed: 122 ins; 242 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/27050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27050/head:pull/27050 PR: https://git.openjdk.org/jdk/pull/27050 From jpai at openjdk.org Tue Sep 2 13:50:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 13:50:43 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. I've verified that this is a clean "git revert" of the original eea50fbc1b24710b18eff4b59dc90dee3736cd95 commit. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176660366 From serb at openjdk.org Tue Sep 2 14:08:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Sep 2025 14:08:48 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176741003 From alanb at openjdk.org Tue Sep 2 14:11:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Sep 2025 14:11:41 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176750059 From syan at openjdk.org Tue Sep 2 14:34:41 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 14:34:41 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176850369 From rriggs at openjdk.org Tue Sep 2 14:58:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 2 Sep 2025 14:58:42 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176950881 From jwaters at openjdk.org Tue Sep 2 15:06:42 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 2 Sep 2025 15:06:42 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: <_JgH1bMAGxiue2ou0w7d57FsUzMu8c2XkfXOtESeZb8=.68d0423b-a0a0-4ea0-ae82-b8c9a4f81c11@github.com> On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Please get this in as soon as possible. ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176979619 From vyazici at openjdk.org Tue Sep 2 15:29:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 15:29:52 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: <8Tf_P9myzruQetqPKRfcN1u4wj1_9b3J--k08F6JKbg=.5a08e454-15c0-4413-ae5f-7ae577b64732@github.com> On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. `tier1` passes on several platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27050#issuecomment-3245815752 From vyazici at openjdk.org Tue Sep 2 15:29:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 15:29:53 GMT Subject: Integrated: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. This pull request has now been integrated. Changeset: ecf05ca5 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/ecf05ca541b32736ab8e8a38d4be4f037a56361d Stats: 462 lines in 8 files changed: 122 ins; 242 del; 98 mod 8366693: Backout recent JavaLangAccess changes breaking the build Reviewed-by: jpai, serb, alanb, syan, rriggs, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/27050 From bpb at openjdk.org Tue Sep 2 18:40:23 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Sep 2025 18:40:23 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: > Add several methods to `java.nio.file.SecureDirectoryStream`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8356493: Path -> T for parameters and return values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26950/files - new: https://git.openjdk.org/jdk/pull/26950/files/8667bca0..b59c3f6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26950&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26950&range=00-01 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26950.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26950/head:pull/26950 PR: https://git.openjdk.org/jdk/pull/26950 From bpb at openjdk.org Tue Sep 2 18:40:23 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Sep 2025 18:40:23 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 14:19:01 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8356493: Path -> T for parameters and return values > > src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 141: > >> 139: * Creates a new and empty file, failing if the file already exists. >> 140: * >> 141: *

This method works in a similar manner to {@linkplain Files#createFile > > I think this method can use "This method works in exactly the manner specified". Fixed in b59c3f6. > src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 171: > >> 169: * @since 26 >> 170: */ >> 171: Path createFile(Path path, FileAttribute... attrs) > > I assume the parameter should be of type T (same comment on the other methods) Fixed in b59c3f6. > src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 250: > >> 248: */ >> 249: Path createLink(T link, SecureDirectoryStream targetdir, T existing) >> 250: throws IOException; > > I realize this models a pair of dfd/path tuples and mklinkat but I wonder about the usability and whether we really need this. In other, maybe we should drop this method from the proposal for now. Could do, but left in for the moment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2316869150 PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2316869283 PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2316869517 From dclarke at openjdk.org Wed Sep 3 12:11:51 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Wed, 3 Sep 2025 12:11:51 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> Message-ID: On Thu, 28 Aug 2025 08:51:14 GMT, Darragh Clarke wrote: >> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. >> >> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. >> >> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. > > Darragh Clarke 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 12 additional commits since the last revision: > > - fixed copyright header > - merged master into branch > - moved repeating code into own method > - implementing feedback, adding missing errno checks, cleanup > - feedback > - general cleanup > - small refactoring > - Performance > - implementing feedback > - removed unrelated change > - ... and 2 more: https://git.openjdk.org/jdk/compare/fbe3c71c...cc5f558a So I double checked the changes made there and wrote this up, I can make it more precise or change wording if its going to be attached to a file. Package info currently contains the script used to generate the code **Common changes:** - utility methods and constant values got moved into FFMUtils, this is to cut down on duplicated code as more FFM code gets added - kqueue_h and kevent both get updated to reference FFMUtils **kqueue_h specific changes:** - Errno handling had to be added, this involved adding the `ADAPTED` method handles as well as editing the `HANDLE` methodhandle to add `Linker.Option.captureCallState(ERRNO_NAME));` - Removing some unused generated objects such as `static final Arena LIBRARY_ARENA = Arena.ofAuto();` - added `private static final String ERRNO_NAME = "errno?;` ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3248980788 From dclarke at openjdk.org Wed Sep 3 15:03:45 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Wed, 3 Sep 2025 15:03:45 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <5134m5ttzdbgrrPBJLbQLC9TsZ8-MyIg9Ky1Js2pMZ4=.f44a3a5d-1c75-4b76-98a8-3344cac98e2d@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> <5134m5ttzdbgrrPBJLbQLC9TsZ8-MyIg9Ky1Js2pMZ4=.f44a3a5d-1c75-4b76-98a8-3344cac98e2d@github.com> Message-ID: On Sat, 30 Aug 2025 15:05:24 GMT, Alan Bateman wrote: >> We could use indices/offsets directly in the methods that receive the slices from this method. > > `getDescriptor(MemorySegment keventArray, int index)` and `getFilter(MemorySegment keventArray, int index)` would work for the use-sites. > > The other thing here is that a fd is an int rather than a long. The re-implemented KQueue should pick ident or fd (the common usage). Right now register takes an int fd, where the modified getDescriptor is actually returning the 64-bit ident. So on my local branch I've address all the comments except the two in this thread, So for using the indices directly what would that look like? would we remove getEvent and instead pass the `MemorySegment` and whatever indices we want to access directly to getDescriptor/getFilter? As for fd/ident, I think that's interesting, the reason for getDescriptor using long ident is because that's what jextract generated for it (from `uintptr_t` specifically), I see that in mainline today it's just the simpler call of ` return unsafe.getInt(address + OFFSET_IDENT);` I could try just replicating the existing code instead of using the generated method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2319266899 From alanb at openjdk.org Wed Sep 3 15:22:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Sep 2025 15:22:52 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> <5134m5ttzdbgrrPBJLbQLC9TsZ8-MyIg9Ky1Js2pMZ4=.f44a3a5d-1c75-4b76-98a8-3344cac98e2d@github.com> Message-ID: On Wed, 3 Sep 2025 15:00:22 GMT, Darragh Clarke wrote: > I could try just replicating the existing code instead of using the generated method? We always use the ident as an fd so don't use the full width. It doesn't matter if KQueue uses int fd or long ident in the API that it exposes but I'd prefer not to have a mix of both, at least not with good naming to avoid mis-use. If you want a preference then expose just the narrow fd form would work best the use-sites. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2319323168 From bpb at openjdk.org Wed Sep 3 17:14:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Sep 2025 17:14:43 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 18:37:32 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 250: >> >>> 248: */ >>> 249: Path createLink(T link, SecureDirectoryStream targetdir, T existing) >>> 250: throws IOException; >> >> I realize this models a pair of dfd/path tuples and mklinkat but I wonder about the usability and whether we really need this. In other, maybe we should drop this method from the proposal for now. > > Could do, but left in for the moment. >> [...] maybe we should drop this method [`createLink`] from the proposal for now. > > Could do, but left in for the moment. It could be moved to a separate issue to be addressed later, or not. I'd prefer to leave it in until there is agreement on the rest of the request, and drop it just before filing the CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2319656937 From bpb at openjdk.org Thu Sep 4 00:35:52 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 4 Sep 2025 00:35:52 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) Message-ID: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/27079/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365626 Stats: 177 lines in 4 files changed: 129 ins; 34 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27079.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27079/head:pull/27079 PR: https://git.openjdk.org/jdk/pull/27079 From duke at openjdk.org Thu Sep 4 04:53:45 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Thu, 4 Sep 2025 04:53:45 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 17:12:31 GMT, Brian Burkhalter wrote: >> Could do, but left in for the moment. > >>> [...] maybe we should drop this method [`createLink`] from the proposal for now. >> >> Could do, but left in for the moment. > > It could be moved to a separate issue to be addressed later, or not. I'd prefer to leave it in until there is agreement on the rest of the request, and drop it just before filing the CSR. For what it's worth, as the author of JDK-8356493, I would use `createLink`. Maybe the usability of simple cases would be improved by a `createLink(T link, T target)` overload (that passed `olddirfd=AT_FDCWD` to the underlying syscall)? I think this may also need a `LinkOption` flag to pass `AT_FOLLOW_SYMLINKS`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2320820004 From vyazici at openjdk.org Thu Sep 4 06:50:18 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 06:50:18 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods Message-ID: [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 ------------- Commit messages: - Further simplify sneaky-throws in `String` - Fix `StringSupport` - Revert "8366693: Backout recent JavaLangAccess changes breaking the build" Changes: https://git.openjdk.org/jdk/pull/27084/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366765 Stats: 465 lines in 9 files changed: 242 ins; 122 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 06:50:18 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 06:50:18 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Commits are consisted of the following: 1. f3e7c130391 Revert the revert 2. 3ea1d5ea009 Fix `StringSupport` 3. b48def1a22d Further simplify sneaky-throws in `String` (via @dfuch) Started `tier1,2` against b48def1a22d on 2025-09-03T07:50:32Z, and it successfully completed on 2025-09-03T14:10:35Z. Results are attached to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252150408 From alanb at openjdk.org Thu Sep 4 07:22:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Sep 2025 07:22:42 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Can you confirm that the only change from before is the update to src/java.base/share/classes/jdk/internal/foreign/StringSupport.java to deal with the "new" usage there? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252266512 From vyazici at openjdk.org Thu Sep 4 07:55:50 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 07:55:50 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> References: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> Message-ID: On Thu, 4 Sep 2025 07:19:39 GMT, Alan Bateman wrote: > Can you confirm that the only change from before is the update to src/java.base/share/classes/jdk/internal/foreign/StringSupport.java to deal with the "new" usage there? @AlanBateman, this PR has *one additional change* to deal with the "new" usage in `StringSupport`: 1. f3e7c130391 Revert the revert 2. 3ea1d5ea009 Deal with `StringSupport` 3. b48def1a22d Further simplify sneaky-throws in `String` (via @dfuch) The diff compared to JDK-8356439 (#26413 eea50fbc) is as follows: git diff eea50fbc...b48def1a -- $(git diff --name-only upstream/master | xargs echo) diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java index 8acb8d8514b..54f74266c08 100644 --- a/src/java.base/share/classes/java/lang/String.java +++ b/src/java.base/share/classes/java/lang/String.java @@ -1348,7 +1348,7 @@ private static int malformed4(byte[] src, int sp) { * having to declare the exception */ @SuppressWarnings("unchecked") - private static E malformedInputException(int offset, int length) throws E { + private static E malformedInputException(int offset, int length) { MalformedInputException mie = new MalformedInputException(length); String msg = "malformed input offset : " + offset + ", length : " + length; mie.initCause(new IllegalArgumentException(msg)); @@ -1359,7 +1359,7 @@ private static E malformedInputException(int offset, int l * {@return a new {@link MalformedInputException} for the given malformed * ASCII string} */ - private static MalformedInputException malformedASCII(byte[] val) throws MalformedInputException { + private static MalformedInputException malformedASCII(byte[] val) { int dp = StringCoding.countPositives(val, 0, val.length); return malformedInputException(dp, 1); } @@ -1371,7 +1371,7 @@ private static MalformedInputException malformedASCII(byte[] val) throws Malform * having to declare the exception */ @SuppressWarnings("unchecked") - private static E unmappableCharacterException(int offset) throws E { + private static E unmappableCharacterException(int offset) { UnmappableCharacterException uce = new UnmappableCharacterException(1); String msg = "malformed input offset : " + offset + ", length : 1"; uce.initCause(new IllegalArgumentException(msg, uce)); @@ -1382,7 +1382,7 @@ private static E unmappableCharacterException(int offset) * {@return a new {@link UnmappableCharacterException} for the given * malformed ASCII string} */ - private static UnmappableCharacterException unmappableASCII(byte[] val) throws UnmappableCharacterException { + private static UnmappableCharacterException unmappableASCII(byte[] val) { int dp = StringCoding.countPositives(val, 0, val.length); return unmappableCharacterException(dp); } diff --git a/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java b/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java index 2f842810aa7..bb6cb2d3915 100644 --- a/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java +++ b/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java @@ -73,7 +73,7 @@ private static String readByte(AbstractMemorySegmentImpl segment, long offset, C final byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); @@ -92,7 +92,7 @@ private static String readShort(AbstractMemorySegmentImpl segment, long offset, byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); @@ -111,7 +111,7 @@ private static String readInt(AbstractMemorySegmentImpl segment, long offset, Ch byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252376320 From alanb at openjdk.org Thu Sep 4 08:29:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Sep 2025 08:29:42 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: <_KvUNOd7WUsV5u8pgeihu3YQqXtvZQUgGs8ehozlA9o=.ce1be4e2-49cd-4b99-b949-eb4f10269e90@github.com> On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3184023515 From aturbanov at openjdk.org Thu Sep 4 09:07:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 09:07:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 src/java.base/share/classes/java/lang/String.java line 691: > 689: } > 690: > 691: /* Is there a reason, why it can't be _converted_ to a proper javadoc? Suggestion: /** src/java.base/share/classes/java/lang/String.java line 797: > 795: * @param cs charset the byte array encoded in > 796: * > 797: * @throws CharacterCodingException for malformed input or unmappable characters Shouldn't we document NPE here too? I mean there is NPE note in `private` method `newStringUTF8OrThrow`, but not in the more widely opened `newStringOrThrow`. That's confusing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321347469 PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321350608 From vyazici at openjdk.org Thu Sep 4 09:41:43 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 09:41:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Improve docs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27084/files - new: https://git.openjdk.org/jdk/pull/27084/files/b48def1a..8d7dcb4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 09:41:45 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 09:41:45 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:01:25 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/java/lang/String.java line 691: > >> 689: } >> 690: >> 691: /* > > Is there a reason, why it can't be _converted_ to a proper javadoc? > Suggestion: > > /** Improved as suggested in 8d7dcb4d410. > src/java.base/share/classes/java/lang/String.java line 797: > >> 795: * @param cs charset the byte array encoded in >> 796: * >> 797: * @throws CharacterCodingException for malformed input or unmappable characters > > Shouldn't we document NPE here too? > I mean there is NPE note in `private` method `newStringUTF8OrThrow`, but not in the more widely opened `newStringOrThrow`. That's confusing. Improved NPE docs in 8d7dcb4d410. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321446143 PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321445517 From duke at openjdk.org Thu Sep 4 09:46:46 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 4 Sep 2025 09:46:46 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Thu, 4 Sep 2025 00:30:52 GMT, Brian Burkhalter wrote: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 477: > 475: @Override > 476: public int hashCode() { > 477: return volSerialNumber + fileIndexHigh + fileIndexLow; Should we combine these values with something more complex than a sum to reduce potential collisions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2321461288 From aturbanov at openjdk.org Thu Sep 4 09:48:45 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 09:48:45 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:41:43 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Improve docs src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 344: > 342: * @return the newly created string > 343: * @throws CharacterCodingException for malformed or unmappable bytes > 344: * @throws NullPointerException If {@code bytes} is null for `null` cs is also thrown ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321465942 From aturbanov at openjdk.org Thu Sep 4 10:05:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 10:05:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> On Thu, 4 Sep 2025 09:41:43 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Improve docs src/java.base/share/classes/java/lang/String.java line 961: > 959: * @throws CharacterCodingException For malformed input or unmappable characters > 960: */ > 961: static byte[] getBytesUTF8OrThrow(String s) throws CharacterCodingException { `encodeUTF8OrThrow(s.coder(), s.value());` specified to throw `UnmappableCharacterException`. May we should to it here too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321506473 From vyazici at openjdk.org Thu Sep 4 11:22:31 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:22:31 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: More nullability improvements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27084/files - new: https://git.openjdk.org/jdk/pull/27084/files/8d7dcb4d..1852dccc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 11:22:32 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:22:32 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:45:57 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 344: > >> 342: * @return the newly created string >> 343: * @throws CharacterCodingException for malformed or unmappable bytes >> 344: * @throws NullPointerException If {@code bytes} is null > > for `null` cs is also thrown Fixed in 1852dccc962. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321712147 From vyazici at openjdk.org Thu Sep 4 11:25:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:25:53 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> References: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> Message-ID: On Thu, 4 Sep 2025 10:03:10 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/java/lang/String.java line 961: > >> 959: * @throws CharacterCodingException For malformed input or unmappable characters >> 960: */ >> 961: static byte[] getBytesUTF8OrThrow(String s) throws CharacterCodingException { > > `encodeUTF8OrThrow(s.coder(), s.value());` specified to throw `UnmappableCharacterException`. May we should to it here too? UCE extends from CCE, hence `throws UCE` is already covered. Plus, what I see from `JLA::*OrThrow` methods, we only declare and document the CCE, not its subclasses. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321722048 From rriggs at openjdk.org Thu Sep 4 13:31:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 13:31:47 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:22:31 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > More nullability improvements Good to go! ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3185310732 From liach at openjdk.org Thu Sep 4 15:05:46 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 15:05:46 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:22:31 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > More nullability improvements Looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3185780567 From bpb at openjdk.org Thu Sep 4 15:30:45 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 4 Sep 2025 15:30:45 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 04:50:32 GMT, Benjamin Peterson wrote: > Maybe the usability of simple cases would be improved by a `createLink(T link, T target)` overload (that passed `olddirfd=AT_FDCWD` to the underlying syscall)? That's a thought. Or maybe have it be the same directory as the link? > I think this may also need a `LinkOption` flag to pass `AT_FOLLOW_SYMLINKS`? This method was intended to mirror `File.createLink` which does not have this option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2322556434 From bpb at openjdk.org Thu Sep 4 15:34:46 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 4 Sep 2025 15:34:46 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Thu, 4 Sep 2025 09:44:01 GMT, Francesco Andreuzzi wrote: > Should we combine these values with something more complex than a sum to reduce potential collisions? This method is there mainly to silence the compilation warning about overriding `equals` while not overriding `hashCode`. Overriding `equals` was necessary for detecting a file system loop (cycle). This class is package scope and I don't think that `hashCode` will ever be used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2322570264 From duke at openjdk.org Thu Sep 4 16:56:47 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Thu, 4 Sep 2025 16:56:47 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:27:36 GMT, Brian Burkhalter wrote: > > Maybe the usability of simple cases would be improved by a `createLink(T link, T target)` overload (that passed `olddirfd=AT_FDCWD` to the underlying syscall)? > > That's a thought. Or maybe have it be the same directory as the link? That seems unnecessarily restrictive, since `secureStream.createLink(link, secureStream, target)` easily accomplishes that with full-featured overload. > > > I think this may also need a `LinkOption` flag to pass `AT_FOLLOW_SYMLINKS`? > > This method was intended to mirror `File.createLink` which does not have this option. Probably because `link(2)` always follows symlinks? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2322795582 From bpb at openjdk.org Thu Sep 4 16:59:47 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 4 Sep 2025 16:59:47 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 16:53:59 GMT, Benjamin Peterson wrote: > > This method was intended to mirror `File.createLink` which does not have this option. > > Probably because `link(2)` always follows symlinks? Good point. I should revise this. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2322802447 From bpb at openjdk.org Thu Sep 4 20:44:42 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 4 Sep 2025 20:44:42 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 16:56:56 GMT, Brian Burkhalter wrote: >>> > Maybe the usability of simple cases would be improved by a `createLink(T link, T target)` overload (that passed `olddirfd=AT_FDCWD` to the underlying syscall)? >>> >>> That's a thought. Or maybe have it be the same directory as the link? >> >> That seems unnecessarily restrictive, since `secureStream.createLink(link, secureStream, target)` easily accomplishes that with full-featured overload. >> >>> >>> > I think this may also need a `LinkOption` flag to pass `AT_FOLLOW_SYMLINKS`? >>> >>> This method was intended to mirror `File.createLink` which does not have this option. >> >> Probably because `link(2)` always follows symlinks? > >> > This method was intended to mirror `File.createLink` which does not have this option. >> >> Probably because `link(2)` always follows symlinks? > > Good point. I should revise this. Thanks. > Maybe the usability of simple cases would be improved by a `createLink(T link, T target)` overload (that passed `olddirfd=AT_FDCWD` to the underlying syscall)? This could also be accomplished by passing as `targetdir` a `SecureDirectoryStream` created for the `Path` of `System.getProperty("user.dir")`. I suppose it depends on how common the case is as to whether a convenience method is worthwhile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2323506922 From duke at openjdk.org Thu Sep 4 21:59:29 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Thu, 4 Sep 2025 21:59:29 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 20:41:46 GMT, Brian Burkhalter wrote: >>> > This method was intended to mirror `File.createLink` which does not have this option. >>> >>> Probably because `link(2)` always follows symlinks? >> >> Good point. I should revise this. Thanks. > >> Maybe the usability of simple cases would be improved by a `createLink(T link, T target)` overload (that passed `olddirfd=AT_FDCWD` to the underlying syscall)? > > This could also be accomplished by passing as `targetdir` a `SecureDirectoryStream` created for the `Path` of `System.getProperty("user.dir")`. > > I suppose it depends on how common the case is as to whether a convenience method is worthwhile. In my particular application, the target is an absolute `Path`, so having to open another directory stream to pass as the target dir would be roundabout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2323616693 From bpb at openjdk.org Thu Sep 4 21:59:31 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 4 Sep 2025 21:59:31 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 21:45:05 GMT, Benjamin Peterson wrote: > In my particular application, the target is an absolute `Path`, so having to open another directory stream to pass as the target dir would be roundabout. Thanks, that's helpful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2323624889 From bpb at openjdk.org Fri Sep 5 01:00:26 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 01:00:26 GMT Subject: RFR: 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) Message-ID: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> Remove all code for normalizing file paths to Unicode Normalization Format D on macOS. This removes support for the system property `jdk.nio.path.useNormalizationFormD`. This change nullifies the effect of the change made for [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). ------------- Commit messages: - 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) Changes: https://git.openjdk.org/jdk/pull/27109/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366911 Stats: 183 lines in 7 files changed: 2 ins; 174 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27109.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27109/head:pull/27109 PR: https://git.openjdk.org/jdk/pull/27109 From bpb at openjdk.org Fri Sep 5 01:00:26 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 01:00:26 GMT Subject: RFR: 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) In-Reply-To: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> References: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> Message-ID: On Thu, 4 Sep 2025 22:45:57 GMT, Brian Burkhalter wrote: > Remove all code for normalizing file paths to Unicode Normalization Format D on macOS. This removes support for the system property `jdk.nio.path.useNormalizationFormD`. This change nullifies the effect of the change made for [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). An existing test was modified but I don't think it provides much value here as it was intended to validate that normalization was being performed. The test should probably either be replaced or removed outright. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27109#issuecomment-3256611336 From vyazici at openjdk.org Fri Sep 5 06:43:21 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 5 Sep 2025 06:43:21 GMT Subject: Integrated: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 This pull request has now been integrated. Changeset: a2f8d3c4 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/a2f8d3c4c25fdadf378313ef52185dceee98773d Stats: 469 lines in 9 files changed: 244 ins; 121 del; 104 mod 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods Reviewed-by: rriggs, liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/27084 From alanb at openjdk.org Fri Sep 5 06:47:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 06:47:11 GMT Subject: RFR: 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) In-Reply-To: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> References: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> Message-ID: On Thu, 4 Sep 2025 22:45:57 GMT, Brian Burkhalter wrote: > Remove all code for normalizing file paths to Unicode Normalization Format D on macOS. This removes support for the system property `jdk.nio.path.useNormalizationFormD`. This change nullifies the effect of the change made for [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 816: > 814: String stringValue = this.stringValue; > 815: if (stringValue == null) { > 816: this.stringValue = stringValue = Util.toString(path); // platform encoding In passing, I think stringValue can be a stable field. test/jdk/java/nio/file/Path/MacPathTest.java line 25: > 23: > 24: /* @test > 25: * @bug 7130915 8289689 8366911 This test has `@run main/othervm -Djdk.nio.path.useNormalizationFormD=true` that I assume should be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27109#discussion_r2324245004 PR Review Comment: https://git.openjdk.org/jdk/pull/27109#discussion_r2324244091 From alanb at openjdk.org Fri Sep 5 06:59:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 06:59:09 GMT Subject: RFR: 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) In-Reply-To: References: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> Message-ID: On Fri, 5 Sep 2025 00:35:42 GMT, Brian Burkhalter wrote: > An existing test was modified but I don't think it provides much value here as it was intended to validate that normalization was being performed. The test should probably either be replaced or removed outright. MacPath has some good tests but will need an update to not check jdk.nio.path.useNormalizationFormD. The "launcher" that is MacPathTest isn't useful now, so maybe MacPath becomes "the test". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27109#issuecomment-3257276991 From alan.bateman at oracle.com Fri Sep 5 09:28:59 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 5 Sep 2025 10:28:59 +0100 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: References: Message-ID: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> On 05/09/2025 09:43, Geliang Tang wrote: > : > > 3. Proposed Java API Changes > > The goal is to allow Java applications to opt-in to using MPTCP when > creating sockets, without breaking existing code. The proposed changes > are additive and backward-compatible. > > The core idea is to add a boolean mptcp parameter through the API > layers, from the public Socket class down to the native system call. (moving the discussion to nio-dev and net-dev). Adding new constructors to legacy Socket/ServerSocket may work for your initial prototype but would be problematic to propose as it would bake non-standard features into the standard API. Also many high performance servers use SocketChannel rather than Socket. One suggestion for a next prototype is to model the enablement of MultiPath TCP as as a JDK-specific socket option (see jdk.net.ExtendingSocketOptions). All of the standard APIs for networking sockets define a setOption method for setting socket options. If modeled as a socket option then enabling can create a new AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place so that the original AF_INET6/SOCK_STREAM/0 socket is closed. Enabling can be made to fail if the socket is already bound. It could copy over existing socket options if needed. Look at the built-in (and no longer used) SDP support for an example that does similar with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a socket option defined in jdk.net.ExtendingSocketOptions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From geliang at kernel.org Fri Sep 5 10:11:22 2025 From: geliang at kernel.org (Geliang Tang) Date: Fri, 05 Sep 2025 18:11:22 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> Message-ID: Hi Alan, Thanks for your reply. On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote: > ? > On 05/09/2025 09:43, Geliang Tang wrote: > ? > ? > > ? > > : > > > > 3. Proposed Java API Changes > > > > The goal is to allow Java applications to opt-in to using MPTCP > > when > > creating sockets, without breaking existing code. The proposed > > changes > > are additive and backward-compatible. > > > > The core idea is to add a boolean mptcp parameter through the API > > layers, from the public Socket class down to the native system > > call. > > ? > ? > ?(moving the discussion to nio-dev and net-dev). > ? > ?Adding new constructors to legacy Socket/ServerSocket may work for > your initial prototype but would be problematic to propose as it > would bake non-standard features into the standard API. Also many > high performance servers use SocketChannel rather than Socket. > ? > ?One suggestion for a next prototype is to model the enablement of > MultiPath TCP as as a JDK-specific socket option (see > jdk.net.ExtendingSocketOptions). All of the standard APIs for > networking sockets define a setOption method for setting socket I was initially concerned that calling setOption() after Socket() creation to convert TCP to MPTCP was too late. Creating an MPTCP socket must be done during the socket() system call. > options. If modeled as a socket option then enabling can create a new > AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place Until I saw here, it should be feasible if the socket can be created again and dup when calling setOption(). I will try to reimplement MPTCP support using jdk.net.ExtendingSocketOptions soon and give you feedback. Thanks, -Geliang > so that the original AF_INET6/SOCK_STREAM/0 socket is closed. > Enabling can be made to fail if the socket is already bound. It could > copy over existing socket options if needed. Look at the built-in > (and no longer used) SDP support for an example that does similar > with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a > socket option defined in jdk.net.ExtendingSocketOptions. > ? > ?-Alan > ? > ? From alanb at openjdk.org Fri Sep 5 12:46:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 12:46:11 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: <3c4aOSVgkOzq6-TBOmMC22vgPuARTUpmYklLcVMgWLY=.fec3acac-6b4b-4b35-818d-48b72ed2d049@github.com> On Thu, 4 Sep 2025 15:32:34 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 477: >> >>> 475: @Override >>> 476: public int hashCode() { >>> 477: return volSerialNumber + fileIndexHigh + fileIndexLow; >> >> Should we combine these values with something more complex than a sum to reduce potential collisions? > >> Should we combine these values with something more complex than a sum to reduce potential collisions? > > This method is there mainly to silence the compilation warning about overriding `equals` while not overriding `hashCode`. Overriding `equals` was necessary for detecting a file system loop (cycle). This class is package scope and I don't think that `hashCode` will ever be used. Methods such as Files.readAttributes will return a WindowsFileAttributes object can't have equals accessing the file system. The API docs don't specify the equality of XXFileAttributes. If specified it would likely be specified based on the value of the snapshot, not just the file key. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2324994820 From alanb at openjdk.org Fri Sep 5 12:51:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 12:51:10 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Thu, 4 Sep 2025 00:30:52 GMT, Brian Burkhalter wrote: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 36: > 34: import java.io.*; > 35: import java.util.*; > 36: import java.util.concurrent.atomic.AtomicLong; ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325006715 From alanb at openjdk.org Fri Sep 5 13:01:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 13:01:10 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Thu, 4 Sep 2025 00:30:52 GMT, Brian Burkhalter wrote: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 484: > 482: } > 483: > 484: if (h != 0L) { I don't think it's possible for the handle to be 0L here. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 493: > 491: } > 492: > 493: if (attrs != null) Same thing here, not possible for attrs to be null, at least not unless we have a bug in readAttributes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325026487 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325027207 From alanb at openjdk.org Fri Sep 5 13:15:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 13:15:11 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Thu, 4 Sep 2025 00:30:52 GMT, Brian Burkhalter wrote: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 462: > 460: handle = h; > 461: > 462: String target = WindowsLinkSupport.readLink(path); If you add WindowsLinkSupport.readLink(handle) then it would avoid close the file, then re-opening it again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325068094 From alanb at openjdk.org Fri Sep 5 13:18:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 13:18:10 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Thu, 4 Sep 2025 00:30:52 GMT, Brian Burkhalter wrote: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 445: > 443: > 444: WindowsFileAttributes attrs = WindowsFileAttributes.readAttributes(h); > 445: if (attrs == null || !attrs.isSymbolicLink()) { I don't think attrs can be null here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325074204 From alanb at openjdk.org Fri Sep 5 13:22:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 13:22:10 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Thu, 4 Sep 2025 00:30:52 GMT, Brian Burkhalter wrote: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 424: > 422: // contains file attributes and its handle > 423: // the attributes' key is valid as long as the handle remains open > 424: private record AttrsAndHandle(WindowsFileAttributes attrs, long handle) {} "the handle remains open" is important. If I read the change correctly then the handle is closed at each step, thus invalidating (in the sense that the file key may be recycled) the entries in the set. I think the closes will need to be done in bulk, in a finally block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325082952 From bpb at openjdk.org Fri Sep 5 15:34:13 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 15:34:13 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Fri, 5 Sep 2025 12:48:57 GMT, Alan Bateman wrote: >> Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 36: > >> 34: import java.io.*; >> 35: import java.util.*; >> 36: import java.util.concurrent.atomic.AtomicLong; > > ? The `AtomicLong` import is vestigial and shall be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325413348 From bpb at openjdk.org Fri Sep 5 15:38:11 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 15:38:11 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: <3c4aOSVgkOzq6-TBOmMC22vgPuARTUpmYklLcVMgWLY=.fec3acac-6b4b-4b35-818d-48b72ed2d049@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <3c4aOSVgkOzq6-TBOmMC22vgPuARTUpmYklLcVMgWLY=.fec3acac-6b4b-4b35-818d-48b72ed2d049@github.com> Message-ID: On Fri, 5 Sep 2025 12:43:17 GMT, Alan Bateman wrote: > Files.readAttributes will return a WindowsFileAttributes object so can't have equals accessing the file system. I don't see where `equals` is accessing the file system. It invokes `WindowsFileAttributes.isSameFile` which uses the volume serial number and file index. Or maybe I missed the point of this comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325422644 From bpb at openjdk.org Fri Sep 5 15:42:11 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 15:42:11 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Fri, 5 Sep 2025 13:19:26 GMT, Alan Bateman wrote: >> Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 424: > >> 422: // contains file attributes and its handle >> 423: // the attributes' key is valid as long as the handle remains open >> 424: private record AttrsAndHandle(WindowsFileAttributes attrs, long handle) {} > > "the handle remains open" is important. If I read the change correctly then the handle is closed at each step, thus invalidating (in the sense that the file key may be recycled) the entries in the set. I think the closes will need to be done in bulk, in a finally block. Unless I got it wrong, the handles remain open only until they are no longer needed, i.e., after comparison of the volume serial numbers and file indices. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325428716 From bpb at openjdk.org Fri Sep 5 15:42:12 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 15:42:12 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Fri, 5 Sep 2025 15:38:29 GMT, Brian Burkhalter wrote: > [...] the handles remain open only until they are no longer needed Actually I think I got this wrong in `lastFileAttrs`; will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325431770 From bpb at openjdk.org Fri Sep 5 16:21:26 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 16:21:26 GMT Subject: RFR: 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) In-Reply-To: References: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> Message-ID: On Fri, 5 Sep 2025 06:56:26 GMT, Alan Bateman wrote: > [...] so maybe MacPath becomes "the test". So changed in 40aadb2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27109#issuecomment-3258934169 From bpb at openjdk.org Fri Sep 5 16:21:27 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 16:21:27 GMT Subject: RFR: 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) [v2] In-Reply-To: References: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> Message-ID: On Fri, 5 Sep 2025 06:44:07 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366911: Remove MacPathTest; tweak MacPath; UnixPath.stringValue -> stable > > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 816: > >> 814: String stringValue = this.stringValue; >> 815: if (stringValue == null) { >> 816: this.stringValue = stringValue = Util.toString(path); // platform encoding > > In passing, I think stringValue can be a stable field. Made stable in 40aadb2. > test/jdk/java/nio/file/Path/MacPathTest.java line 25: > >> 23: >> 24: /* @test >> 25: * @bug 7130915 8289689 8366911 > > This test has `@run main/othervm -Djdk.nio.path.useNormalizationFormD=true` that I assume should be removed. Removed in 40aadb2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27109#discussion_r2325515003 PR Review Comment: https://git.openjdk.org/jdk/pull/27109#discussion_r2325514728 From bpb at openjdk.org Fri Sep 5 16:21:25 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 16:21:25 GMT Subject: RFR: 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) [v2] In-Reply-To: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> References: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> Message-ID: > Remove all code for normalizing file paths to Unicode Normalization Format D on macOS. This removes support for the system property `jdk.nio.path.useNormalizationFormD`. This change nullifies the effect of the change made for [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8366911: Remove MacPathTest; tweak MacPath; UnixPath.stringValue -> stable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27109/files - new: https://git.openjdk.org/jdk/pull/27109/files/9f27ffb2..40aadb21 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27109&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27109&range=00-01 Stats: 93 lines in 3 files changed: 16 ins; 72 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27109.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27109/head:pull/27109 PR: https://git.openjdk.org/jdk/pull/27109 From bpb at openjdk.org Fri Sep 5 17:02:10 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 17:02:10 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 21:50:37 GMT, Brian Burkhalter wrote: >> In my particular application, the target is an absolute `Path`, so having to open another directory stream to pass as the target dir would be roundabout. > >> In my particular application, the target is an absolute `Path`, so having to open another directory stream to pass as the target dir would be roundabout. > > Thanks, that's helpful. > I think this may also need a `LinkOption` flag to pass `AT_FOLLOW_SYMLINKS`? Adding `LinkOption.FOLLOW_LINKS` could be confusing when there is already `LinkOption.NOFOLLOW_LINKS`. For consistency with the `Files` APIs, it might be better to follow links by default (`AT_SYMLINK_FOLLOW`). Also, the macOS man page for `linkat` states On OS X, not assigning AT_SYMLINK_FOLLOW to flag may result in some file systems returning an error. which is not encouraging. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2325612518 From alanb at openjdk.org Fri Sep 5 17:06:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 17:06:09 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <3c4aOSVgkOzq6-TBOmMC22vgPuARTUpmYklLcVMgWLY=.fec3acac-6b4b-4b35-818d-48b72ed2d049@github.com> Message-ID: On Fri, 5 Sep 2025 15:35:47 GMT, Brian Burkhalter wrote: >> Methods such as Files.readAttributes will return a WindowsFileAttributes object so can't have equals accessing the file system. The API docs don't specify the equality of XXFileAttributes. If specified it would likely be specified based on the value of the snapshot, not just the file key. > >> Files.readAttributes will return a WindowsFileAttributes object so can't have equals accessing the file system. > > I don't see where `equals` is accessing the file system. It invokes `WindowsFileAttributes.isSameFile` which uses the volume serial number and file index. Or maybe I missed the point of this comment. Okay, but the concern is that user code may be stashing XXFileAttribute objects into collections so we can't have equals/hashCode be based solely on the file key when that is only reliable when the file is open. Also equality is problematic when the timestamps or other values aren't equal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325619421 From bpb at openjdk.org Fri Sep 5 17:37:09 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Sep 2025 17:37:09 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <3c4aOSVgkOzq6-TBOmMC22vgPuARTUpmYklLcVMgWLY=.fec3acac-6b4b-4b35-818d-48b72ed2d049@github.com> Message-ID: On Fri, 5 Sep 2025 17:03:37 GMT, Alan Bateman wrote: >>> Files.readAttributes will return a WindowsFileAttributes object so can't have equals accessing the file system. >> >> I don't see where `equals` is accessing the file system. It invokes `WindowsFileAttributes.isSameFile` which uses the volume serial number and file index. Or maybe I missed the point of this comment. > > Okay, but the concern is that user code may be stashing XXFileAttribute objects into collections so we can't have equals/hashCode be based solely on the file key when that is only reliable when the file is open. Also equality is problematic when the timestamps or other values aren't equal. I'll change it to work without `equals`. I don't think it's essential. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2325679532 From duke at openjdk.org Fri Sep 5 20:21:12 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Fri, 5 Sep 2025 20:21:12 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 16:59:35 GMT, Brian Burkhalter wrote: >>> In my particular application, the target is an absolute `Path`, so having to open another directory stream to pass as the target dir would be roundabout. >> >> Thanks, that's helpful. > >> I think this may also need a `LinkOption` flag to pass `AT_FOLLOW_SYMLINKS`? > > Adding `LinkOption.FOLLOW_LINKS` could be confusing when there is already `LinkOption.NOFOLLOW_LINKS`. For consistency with the `Files` APIs, it might be better to follow links by default (`AT_SYMLINK_FOLLOW`). Also, the macOS man page for `linkat` states > > On OS X, not assigning AT_SYMLINK_FOLLOW to flag may result in > some file systems returning an error. > > which is not encouraging. I agree that including `AT_SYMLINK_FOLLOW` by default and optionally taking `LinkOption.NOFOLLOW_LINKS` would be most consistent with the rest of the API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26950#discussion_r2325969115 From alanb at openjdk.org Sat Sep 6 16:04:12 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 6 Sep 2025 16:04:12 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <3c4aOSVgkOzq6-TBOmMC22vgPuARTUpmYklLcVMgWLY=.fec3acac-6b4b-4b35-818d-48b72ed2d049@github.com> Message-ID: On Fri, 5 Sep 2025 17:34:34 GMT, Brian Burkhalter wrote: >> Okay, but the concern is that user code may be stashing XXFileAttribute objects into collections so we can't have equals/hashCode be based solely on the file key when that is only reliable when the file is open. Also equality is problematic when the timestamps or other values aren't equal. > > I'll change it to work without `equals`. I don't think it's essential. One thing to try is renaming AttrsAndHandle to LinkAttributes and have it override equals/hashCode. That will also solve the issue with keeping the handle to each open link. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2327792953 From alanb at openjdk.org Mon Sep 8 06:39:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Sep 2025 06:39:14 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> Message-ID: On Wed, 3 Sep 2025 12:08:49 GMT, Darragh Clarke wrote: > So I double checked the changes made there and wrote this up, I can make it more precise or change wording if its going to be attached to a file. Package info currently contains the script used to generate the code > > **Common changes:** > > * utility methods and constant values got moved into FFMUtils, this is to cut down on duplicated code as more FFM code gets added > * kqueue_h and kevent both get updated to reference FFMUtils > * `@SuppressWarnings("restricted")` is added above the class declarations > > **kqueue_h specific changes:** > > * Errno handling had to be added, this involved adding the `ADAPTED` method handles as well as editing the `HANDLE` methodhandle to add `Linker.Option.captureCallState(ERRNO_NAME));` > * Removing some unused generated objects such as `static final Arena LIBRARY_ARENA = Arena.ofAuto();` > * added `private static final String ERRNO_NAME = "errno?;` It might also help if the integration were split into two. A first commit with the jextract-generated files, then a second that has the changes. That would capture in the git log the changes that were made, and would also make things much easier to review too as it would be obvious what has been changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3264814812 From bpb at openjdk.org Mon Sep 8 19:53:29 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 8 Sep 2025 19:53:29 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v3] In-Reply-To: References: Message-ID: > Add several methods to `java.nio.file.SecureDirectoryStream`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8356493: make createFile accept LinkOption ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26950/files - new: https://git.openjdk.org/jdk/pull/26950/files/b59c3f6c..77df1437 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26950&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26950&range=01-02 Stats: 26 lines in 6 files changed: 12 ins; 4 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26950.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26950/head:pull/26950 PR: https://git.openjdk.org/jdk/pull/26950 From bpb at openjdk.org Mon Sep 8 19:53:30 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 8 Sep 2025 19:53:30 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v2] In-Reply-To: References: Message-ID: <7eVhNyUvRB1jgT12nOvUc35rs0C1FQ9o0w2TgEdpGmA=.8a957b26-222c-4f0d-8540-724b258ceb72@github.com> On Tue, 2 Sep 2025 18:40:23 GMT, Brian Burkhalter wrote: >> Add several methods to `java.nio.file.SecureDirectoryStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8356493: Path -> T for parameters and return values Commit 77df143 modifies `createLink` to accept a `LinkOption` parameter and to have a `null` value of `targetdir` indicate the current working directory. The test is changed only to accept a `null` value for `targetdir`, with further updates pending whether this proposal will actually include `createLink`. In the event, the test should probably be converted to JUnit 5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26950#issuecomment-3267720081 From bpb at openjdk.org Tue Sep 9 00:30:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Sep 2025 00:30:43 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v2] In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8365626: Incorporate suggestions from review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/347a8b1e..84a880b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=00-01 Stats: 102 lines in 3 files changed: 30 ins; 26 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/27079.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27079/head:pull/27079 PR: https://git.openjdk.org/jdk/pull/27079 From swen at openjdk.org Tue Sep 9 08:13:40 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 9 Sep 2025 08:13:40 GMT Subject: Withdrawn: Re-examine buffering and encoding conversion in BufferedWriter In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 16:48:40 GMT, Shaojin Wen wrote: > BufferedWriter -> OutputStreamWriter -> StreamEncoder > > In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. > > LATIN1 -> UTF16 -> UTF8 > > We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26022 From alanb at openjdk.org Tue Sep 9 13:21:21 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Sep 2025 13:21:21 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v2] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Tue, 9 Sep 2025 00:30:43 GMT, Brian Burkhalter wrote: >> Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8365626: Incorporate suggestions from review comments src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 96: > 94: * Returns the target of a symbolic link > 95: */ > 96: static String readLink(WindowsPath path, long handle) throws IOException { It might be better to rename readLinkImpl to readLink and make it non-public, maybe you've tried this already? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2333568800 From alanb at openjdk.org Tue Sep 9 13:25:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Sep 2025 13:25:48 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v2] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: <18ebUo-_KkgrLESGmUecNHE_6iUCfRsKRYqbEry7kcs=.5b194bae-0677-407d-acfe-d64ac2f73b72@github.com> On Tue, 9 Sep 2025 00:30:43 GMT, Brian Burkhalter wrote: >> Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8365626: Incorporate suggestions from review comments src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 464: > 462: LinkAttributes linkAttr = new LinkAttributes(attrs, h); > 463: if (!fileAttrs.add(linkAttr)) > 464: throw new FileSystemLoopException("Looping symbolic link"); The parameter to FileSystemLoopException is the file that caused the loop rather than a message. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 471: > 469: path = WindowsPath.parse(path.getFileSystem(), target); > 470: } > 471: } catch (Exception e) { I assume this should IOException|WindowsException rather than Exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2333584595 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2333589764 From alanb at openjdk.org Tue Sep 9 13:30:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Sep 2025 13:30:58 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v2] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Tue, 9 Sep 2025 00:30:43 GMT, Brian Burkhalter wrote: >> Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8365626: Incorporate suggestions from review comments Latest version looks quite good, just a few comments. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 429: > 427: return true; > 428: if (obj instanceof LinkAttributes other) > 429: return WindowsFileAttributes.isSameFile(attrs, other.attrs()); It's not obvious that this consistent with hashCode. It might be better to have this check the that the 3 values are equal. ------------- PR Review: https://git.openjdk.org/jdk/pull/27079#pullrequestreview-3201604569 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2333603276 From bpb at openjdk.org Tue Sep 9 15:33:12 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Sep 2025 15:33:12 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v2] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Tue, 9 Sep 2025 13:18:47 GMT, Alan Bateman wrote: > [...] rename readLinkImpl to readLink and make it non-public [...] By "non-public" do you intend package scope? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2334022988 From alanb at openjdk.org Tue Sep 9 17:24:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Sep 2025 17:24:51 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v2] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: <5sCblp37ZT4KCFOWlGWz62s-lPBCnMY2f-w1tYW2IL8=.0cf42f33-70c6-4b19-8263-d6c2a317f0e9@github.com> On Tue, 9 Sep 2025 15:30:24 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 96: >> >>> 94: * Returns the target of a symbolic link >>> 95: */ >>> 96: static String readLink(WindowsPath path, long handle) throws IOException { >> >> It might be better to rename readLinkImpl to readLink and make it non-public, maybe you've tried this already? > >> [...] rename readLinkImpl to readLink and make it non-public [...] > > By "non-public" do you intend package scope? Yes, so that the renamed readLinkImpl is accessible in the package. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2334294176 From bpb at openjdk.org Tue Sep 9 20:27:11 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Sep 2025 20:27:11 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v3] In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8365626: Address reviewer comments since previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/84a880b0..bd4b94df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=01-02 Stats: 18 lines in 2 files changed: 4 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27079.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27079/head:pull/27079 PR: https://git.openjdk.org/jdk/pull/27079 From bpb at openjdk.org Tue Sep 9 20:39:21 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Sep 2025 20:39:21 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v2] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Tue, 9 Sep 2025 13:26:05 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8365626: Incorporate suggestions from review comments > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 429: > >> 427: return true; >> 428: if (obj instanceof LinkAttributes other) >> 429: return WindowsFileAttributes.isSameFile(attrs, other.attrs()); > > It's not obvious that this consistent with hashCode. It might be better to have this check the that the 3 values are equal. Fixed in bd4b94d. > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 464: > >> 462: LinkAttributes linkAttr = new LinkAttributes(attrs, h); >> 463: if (!fileAttrs.add(linkAttr)) >> 464: throw new FileSystemLoopException("Looping symbolic link"); > > The parameter to FileSystemLoopException is the file that caused the loop rather than a message. Fixed in bd4b94d. > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 471: > >> 469: path = WindowsPath.parse(path.getFileSystem(), target); >> 470: } >> 471: } catch (Exception e) { > > I assume this should IOException|WindowsException rather than Exception. Fixed in bd4b94d. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2334714487 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2334713254 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2334714190 From bpb at openjdk.org Tue Sep 9 22:43:05 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Sep 2025 22:43:05 GMT Subject: RFR: 8356493: (fs) SecureDirectoryStream missing some capabilities [v3] In-Reply-To: References: Message-ID: <8kgPAD7Nnp0ye0LBxrCG-xy0QuSSHSKkkoAnxdpLuds=.0e61a6d6-31d3-4f33-bce6-507d7e0675d7@github.com> On Mon, 8 Sep 2025 19:53:29 GMT, Brian Burkhalter wrote: >> Add several methods to `java.nio.file.SecureDirectoryStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8356493: make createFile accept LinkOption Note that the message of commit 77df143 should have been "make createLink accept LinkOption". ------------- PR Comment: https://git.openjdk.org/jdk/pull/26950#issuecomment-3272499672 From bpb at openjdk.org Tue Sep 9 23:23:46 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Sep 2025 23:23:46 GMT Subject: RFR: 8367284: (fs) Support current working directory target in SecureDirectoryStream.move Message-ID: Change `java.nio.file.SecureDirectoryStream.move` so that, instead of throwing a `NullPointerException` if the `targetdir` parameter is `null`, it considers a non-absolute path passed via `targetpath` as being relative to the current working directory. ------------- Commit messages: - 8367284: Update test after all - 8367284: (fs) Support current working directory target in SecureDirectoryStream.move Changes: https://git.openjdk.org/jdk/pull/27178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367284 Stats: 45 lines in 3 files changed: 28 ins; 6 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27178/head:pull/27178 PR: https://git.openjdk.org/jdk/pull/27178 From bpb at openjdk.org Tue Sep 9 23:23:47 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Sep 2025 23:23:47 GMT Subject: RFR: 8367284: (fs) Support current working directory target in SecureDirectoryStream.move In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 23:04:41 GMT, Brian Burkhalter wrote: > Change `java.nio.file.SecureDirectoryStream.move` so that, instead of throwing a `NullPointerException` if the `targetdir` parameter is `null`, it considers a non-absolute path passed via `targetpath` as being relative to the current working directory. This change has a minor collision with #26950. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27178#issuecomment-3272556349 From alanb at openjdk.org Wed Sep 10 13:01:25 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 10 Sep 2025 13:01:25 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v3] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Tue, 9 Sep 2025 20:27:11 GMT, Brian Burkhalter wrote: >> Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8365626: Address reviewer comments since previous commit I think the algorithm is okay but I think this patch is going to take several rounds of cleanup. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 424: > 422: // contains file attributes and its handle > 423: // the attributes' key is valid as long as the handle remains open > 424: private record LinkAttributes(WindowsFileAttributes attrs, long handle) { Can you put a /** .. */ class description on this record. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 444: > 442: > 443: // find the attributes of the last accessible link in the chain > 444: private LinkAttributes lastFileAttrs(WindowsPath path) Maybe rename to lastLinkAttributes ? src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 444: > 442: > 443: // find the attributes of the last accessible link in the chain > 444: private LinkAttributes lastFileAttrs(WindowsPath path) Can we put a more complete /** .. */ method description on this method. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 447: > 445: throws IOException, WindowsException > 446: { > 447: var fileAttrs = new HashSet(); The naming here is problematic as this is a set of link attributes. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 462: > 460: > 461: WindowsFileAttributes attrs = > 462: WindowsFileAttributes.readAttributes(h); Spurious line break here. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 490: > 488: > 489: // find the key by following links > 490: private LinkAttributes fileAttrs(WindowsPath file) throws WindowsException { The comment doesn't work for this method. Can we find a better name for this method and put a more complete method description? src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 526: > 524: if (!(obj2 instanceof WindowsPath)) > 525: return false; > 526: WindowsPath file2 = (WindowsPath)obj2; You can use instanceof WindowsPath file2 to avoid the cast. src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 293: > 291: */ > 292: static String readLink(WindowsPath path, long handle) throws IOException > 293: { Minor formatting nit, the "{" can move to the previous line. ------------- PR Review: https://git.openjdk.org/jdk/pull/27079#pullrequestreview-3205969709 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336672995 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336636371 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336674414 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336675152 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336676016 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336677771 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336632022 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336626428 From alanb at openjdk.org Wed Sep 10 13:01:27 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 10 Sep 2025 13:01:27 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v3] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Fri, 5 Sep 2025 15:31:38 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 36: >> >>> 34: import java.io.*; >>> 35: import java.util.*; >>> 36: import java.util.concurrent.atomic.AtomicLong; >> >> ? > > The `AtomicLong` import is vestigial and shall be removed. I assume you will remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2336628001 From bpb at openjdk.org Wed Sep 10 16:37:06 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Sep 2025 16:37:06 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v3] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: <7XJnVwC2rVwxQXhoOmOuZOAYSrozSWXT5Kp72a9yrq0=.2e7c3000-edae-4c28-9c73-70657e5d4be8@github.com> On Wed, 10 Sep 2025 12:55:46 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8365626: Address reviewer comments since previous commit > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 424: > >> 422: // contains file attributes and its handle >> 423: // the attributes' key is valid as long as the handle remains open >> 424: private record LinkAttributes(WindowsFileAttributes attrs, long handle) { > > Can you put a /** .. */ class description on this record. I am not completely comfortable with the name of this record as it can contain attributes from either a file or a link. Its purpose is to contain the open handle corresponding to the attributes object so it can be closed once the attributes are no longer needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2337299783 From bpb at openjdk.org Wed Sep 10 16:45:02 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Sep 2025 16:45:02 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v3] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Wed, 10 Sep 2025 12:57:29 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8365626: Address reviewer comments since previous commit > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 490: > >> 488: >> 489: // find the key by following links >> 490: private LinkAttributes fileAttrs(WindowsPath file) throws WindowsException { > > The comment doesn't work for this method. Can we find a better name for this method and put a more complete method description? This method in effect attempts to provide the attributes of the path which would be returned by `file.toRealPath()`, returning `null` where that method would throw `NoSuchFileException`. So maybe something like `realPathAttrs`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2337317059 From bpb at openjdk.org Wed Sep 10 17:00:44 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Sep 2025 17:00:44 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v3] In-Reply-To: <7XJnVwC2rVwxQXhoOmOuZOAYSrozSWXT5Kp72a9yrq0=.2e7c3000-edae-4c28-9c73-70657e5d4be8@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <7XJnVwC2rVwxQXhoOmOuZOAYSrozSWXT5Kp72a9yrq0=.2e7c3000-edae-4c28-9c73-70657e5d4be8@github.com> Message-ID: On Wed, 10 Sep 2025 16:33:55 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 424: >> >>> 422: // contains file attributes and its handle >>> 423: // the attributes' key is valid as long as the handle remains open >>> 424: private record LinkAttributes(WindowsFileAttributes attrs, long handle) { >> >> Can you put a /** .. */ class description on this record. > > I am not completely comfortable with the name of this record as it can contain attributes from either a file or a link. Its purpose is to contain the open handle corresponding to the attributes object so it can be closed once the attributes are no longer needed. Maybe `EntryAttributes`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2337352276 From brian.burkhalter at oracle.com Wed Sep 10 20:07:47 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Sep 2025 20:07:47 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: Message-ID: Hello David, Redirecting to nio-dev. On Sep 10, 2025, at 12:01?PM, David Alayachew wrote: One would expect only fileZ.html to be printed out, but nothing does. The reason why is because path.endsWith(String) is effectively an alias for path.endsWith(Path.of(String)). The confusion being that Path.of(someString) is looking for a file or a directory. Thus, since there is neither a file nor a folder called "html", the stream prints out nothing. The specification looks like it is pretty clear about the behavior, especially the implementation note in Path.endsWith(String): "The default implementation is equivalent for this path to: endsWith(getFileSystem().getPath(other));" What you were expecting sounds like what would be given by .filter(path -> path.toString().endsWith("html?)) or better .filter(path -> path.getFileName().toString().endsWith("html?)) Is that correct? If we could eventually agree on how to handle file extensions, that would help here. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Sep 10 20:38:48 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Sep 2025 20:38:48 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: Message-ID: <9F189EDF-86E9-45FA-8F6B-727123D223A0@oracle.com> Hello David, On Sep 10, 2025, at 1:28?PM, David Alayachew wrote: Yes exactly. And I'm not trying to say that the method is underspecified -- the javadoc is fairly clear. I'm merely saying that this overload adds little value, while being a tripping hazard for those thinking the name describes the obvious. So, I'd like to deprecate the overload. Those who want the overload, just use the suggestion in the javadocs. There are a number of methods in Path which are the same except for String- vs. Path-valued parameters. I?m not sure we?d want to deprecate just this one although I do see your point. Perhaps some additional disambiguating verbiage in the endsWith(String) specification would help? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Wed Sep 10 22:31:13 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Sep 2025 22:31:13 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v4] In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: > Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8365626: Address reviewer comments since previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/bd4b94df..d8f65a08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=02-03 Stats: 62 lines in 2 files changed: 28 ins; 4 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/27079.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27079/head:pull/27079 PR: https://git.openjdk.org/jdk/pull/27079 From alanb at openjdk.org Thu Sep 11 09:05:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Sep 2025 09:05:05 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v4] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Wed, 10 Sep 2025 22:31:13 GMT, Brian Burkhalter wrote: >> Improve handling of broken symbolic links in `Files.isSameFile` on Windows as was done on Unix by the fix of [JDK-8154364](https://bugs.openjdk.org/browse/JDK-8154364). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8365626: Address reviewer comments since previous commit src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 483: > 481: EntryAttributes linkAttr = new EntryAttributes(attrs, h); > 482: if (!linkAttrs.add(linkAttr)) > 483: throw new FileSystemLoopException(path.toString()); Is this handle closed if FileSystemLoopException is thrown? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2339607503 From alanb at openjdk.org Thu Sep 11 09:06:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Sep 2025 09:06:57 GMT Subject: RFR: 8291652: (ch) java/nio/channels/SocketChannel/VectorIO.java failed with "Exception: Server 15: Timed out" In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 15:58:16 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which proposes to address an intermittent test failure in `java/nio/channels/SocketChannel/VectorIO.java`? > > As noted in https://bugs.openjdk.org/browse/JDK-8291652, this test has been failing intermittently in our CI. Some years back the test was improved to include additional debug logs to identify the root cause https://bugs.openjdk.org/browse/JDK-8180085. In a recent failure, these test logs indicate that the `Server` thread hadn't yet `accept()`ed a Socket connection, when the client side of the test threw an exception because it had waited for 8 seconds for the server side of the test to complete. > > The change in this PR updates the test to wait for the `Server` thread to reach a point where it is ready to `accept()` a Socket connection. Only after it reaches this state, the client side of the testing will be initiated. Furthermore, the artificial 8 second wait has been removed from this test and it now waits as long as it takes for the testing to complete. If the test waits far too long then the jtreg infrastructure will timeout the test and at the same time capture the necessary artifacts to help debug unexpected time outs. > > While at it, the test has also been updated to use `InetAddress.getLoopbackAddress()` instead of localhost. This should prevent any unexpected address mappings for localhost from playing a role in this test. > > With these changes, I've run the test more than 1000 times in our CI and it hasn't failed. @dfuch Would you have cycles to look at this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26049#issuecomment-3279332901 From alanb at openjdk.org Thu Sep 11 09:07:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Sep 2025 09:07:00 GMT Subject: RFR: 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) [v2] In-Reply-To: References: <2Jze9iDIVLnF3alQGTwbbBjTYbPjc1Qh_tin50PGUL8=.f0e7bc05-3b2c-4f87-b0c1-b4be860d1cbb@github.com> Message-ID: On Fri, 5 Sep 2025 16:21:25 GMT, Brian Burkhalter wrote: >> Remove all code for normalizing file paths to Unicode Normalization Format D on macOS. This removes support for the system property `jdk.nio.path.useNormalizationFormD`. This change nullifies the effect of the change made for [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8366911: Remove MacPathTest; tweak MacPath; UnixPath.stringValue -> stable Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27109#pullrequestreview-3210058962