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 From msheppar at openjdk.org Thu Sep 11 11:38:33 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 11 Sep 2025 11:38:33 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. test/jdk/java/nio/channels/SocketChannel/VectorIO.java line 135: > 133: this.testSize = testSize; > 134: InetAddress loopback = InetAddress.getLoopbackAddress(); > 135: this.ssc = ServerSocketChannel.open().bind(new InetSocketAddress(loopback, 0)); I think it's better to use the two arg version of bind and specify a backlog e.g. 5 to provide consistent behaviour across all OS platforms c.f. Stevens Unix network programming 3rd edition page 106 for recommendation against backlog 0 test/jdk/java/nio/channels/SocketChannel/VectorIO.java line 149: > 147: // await for the server to be ready to accept the > 148: // connections from the client/test > 149: private void waitToStartTest() throws InterruptedException { refactor rename waitServerStart test/jdk/java/nio/channels/SocketChannel/VectorIO.java line 174: > 172: > 173: ssc.configureBlocking(false); > 174: connAcceptLatch.countDown(); refactor extract method signalServerStart for symmetry with waitServerStart ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26049#discussion_r2340332952 PR Review Comment: https://git.openjdk.org/jdk/pull/26049#discussion_r2340340518 PR Review Comment: https://git.openjdk.org/jdk/pull/26049#discussion_r2340345892 From bpb at openjdk.org Thu Sep 11 15:09:48 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 11 Sep 2025 15:09:48 GMT Subject: Integrated: 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: <27EJ6iaAzTXCZGbyRzSGXxJMJAlHa_pq1JoL83zJ0iY=.a7486e60-fbf8-4cb5-a7bd-604b24dacc8a@github.com> 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). This pull request has now been integrated. Changeset: 7603e96f Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/7603e96fa2350c18464fd5dac6bd2c8f140e04c9 Stats: 269 lines in 7 files changed: 16 ins; 244 del; 9 mod 8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS) Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/27109 From bpb at openjdk.org Thu Sep 11 15:16:56 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 11 Sep 2025 15:16:56 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 Thu, 11 Sep 2025 09:02:07 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 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? I think so: `lastLinkAttributes.handle()` is closed in the catch block if `lastLinkAttributes` is not null, and any other handle in `linkAttrs` is closed in the finally block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2341376459 From jpai at openjdk.org Fri Sep 12 10:40:22 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 10:40:22 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. src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 199: > 197: * by the {@code targetdir} parameter, unless {@code targetdir} is > 198: * {@code null}, in which case it is located relative to the current > 199: * working directory. In all cases, if the target file exists then it is Hello Brian, This is the first time I'm seeing this interface so I have some very basic questions. Is there a difference between working directory and open directory in context of this interface? The class level javadoc and several other places of this interface use "open directory" as a term to specify the semantics of these methods. I'm a bit surprised by this interface in general. It has a type parameter `T` and also these methods work on that type, and `T` can be anything and not just a `java.nio.file.Path` type. But this entire interface appears to be for `Path` based operations: public interface SecureDirectoryStream extends DirectoryStream ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2343803297 From alanb at openjdk.org Fri Sep 12 10:58:21 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Sep 2025 10:58:21 GMT Subject: RFR: 8367284: (fs) Support current working directory target in SecureDirectoryStream.move In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 10:37:11 GMT, Jaikiran Pai 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. > > src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 199: > >> 197: * by the {@code targetdir} parameter, unless {@code targetdir} is >> 198: * {@code null}, in which case it is located relative to the current >> 199: * working directory. In all cases, if the target file exists then it is > > Hello Brian, This is the first time I'm seeing this interface so I have some very basic questions. Is there a difference between working directory and open directory in context of this interface? The class level javadoc and several other places of this interface use "open directory" as a term to specify the semantics of these methods. > > I'm a bit surprised by this interface in general. It has a type parameter `T` and also these methods work on that type, and `T` can be anything and not just a `java.nio.file.Path` type. But this entire interface appears to be for `Path` based operations: > > > public interface SecureDirectoryStream > extends DirectoryStream > ... The type parameter is because it was design to support file IDs and other ways to address files. These other approaches didn't really materilize so it's only currently used with Path objects. So a somewhat niche API. I think it needs thinking before adding to it. Advanced cases that want to go to *at syscalls can use FFM, they don't need to use this API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2343840958 From alanb at openjdk.org Fri Sep 12 12:23:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Sep 2025 12:23:19 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 Thu, 11 Sep 2025 15:13:47 GMT, Brian Burkhalter wrote: >> 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? > > I think so: `lastLinkAttributes.handle()` is closed in the catch block if `lastLinkAttributes` is not null, and any other handle in `linkAttrs` is closed in the finally block. Let's go back to L477. If the readAttributes throws then here is the handle closed? The handle is local to the block and isn't encapsulated by an EntryAttributes at this point. I think it would leak but maybe I've missed something, do you mind checking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2344076439 From bpb at openjdk.org Fri Sep 12 16:12:18 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 12 Sep 2025 16:12:18 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 Fri, 12 Sep 2025 12:19:34 GMT, Alan Bateman wrote: > Let's go back to L477. If the readAttributes throws, where is the handle closed? Oh, you're correct: that looks like a leak. The variable `h` should be closed in a catch block for `readAttributes`. Will fix. Thanks for the "catch". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2344717659 From bpb at openjdk.org Fri Sep 12 17:01:13 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 12 Sep 2025 17:01:13 GMT Subject: RFR: 8367284: (fs) Support current working directory target in SecureDirectoryStream.move In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 10:37:11 GMT, Jaikiran Pai 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. > > src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 199: > >> 197: * by the {@code targetdir} parameter, unless {@code targetdir} is >> 198: * {@code null}, in which case it is located relative to the current >> 199: * working directory. In all cases, if the target file exists then it is > > Hello Brian, This is the first time I'm seeing this interface so I have some very basic questions. Is there a difference between working directory and open directory in context of this interface? The class level javadoc and several other places of this interface use "open directory" as a term to specify the semantics of these methods. > > I'm a bit surprised by this interface in general. It has a type parameter `T` and also these methods work on that type, and `T` can be anything and not just a `java.nio.file.Path` type. But this entire interface appears to be for `Path` based operations: > > > public interface SecureDirectoryStream > extends DirectoryStream > ... Hello @jaikiran. > Is there a difference between working directory and open directory in context of this interface? The class level javadoc and several other places of this interface use "open directory" as a term to specify the semantics of these methods. The "open directory" is the one which was passed to `Files.newDirectoryStream` to create the `SecureDirectoryStream`. The working directory is as usual the value of the system property "user.dir" and the value obtained by the library function `getcwd`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2344916661 From bpb at openjdk.org Fri Sep 12 17:12:58 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 12 Sep 2025 17:12:58 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v5] 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: Close handle if readAttributes() throws ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/d8f65a08..82e73a7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=03-04 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 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 Fri Sep 12 17:34:23 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Sep 2025 17:34:23 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 Fri, 12 Sep 2025 16:08:58 GMT, Brian Burkhalter wrote: >> Let's go back to L477. If the readAttributes throws, where is the handle closed? The handle is local to the block and isn't encapsulated by an EntryAttributes at this point. I think it would leak but maybe I've missed something, do you mind checking? > >> Let's go back to L477. If the readAttributes throws, where is the handle closed? > > Oh, you're correct: that looks like a leak. The variable `h` should be closed in a catch block for `readAttributes`. Will fix. Thanks for the "catch". Same question with the code that follows where it checks !attrs.isSymbolicLink(). Does it leak for this case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2345002690 From bpb at openjdk.org Fri Sep 12 17:56:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 12 Sep 2025 17:56:28 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 Fri, 12 Sep 2025 17:31:26 GMT, Alan Bateman wrote: >>> Let's go back to L477. If the readAttributes throws, where is the handle closed? >> >> Oh, you're correct: that looks like a leak. The variable `h` should be closed in a catch block for `readAttributes`. Will fix. Thanks for the "catch". > > Same question with the code that follows where it checks !attrs.isSymbolicLink(). Does it leak for this case? attrs.isSymbolicLink() does not throw nor does any other code before the handle is added to the linkAttrs set and all the handles in there are closed in either the catch or the finally block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2345044374 From alanb at openjdk.org Sat Sep 13 07:19:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Sep 2025 07:19:45 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 Fri, 12 Sep 2025 17:53:17 GMT, Brian Burkhalter wrote: >> Same question with the code that follows where it checks !attrs.isSymbolicLink(). Does it leak for this case? > > attrs.isSymbolicLink() does not throw nor does any other code before the handle is added to the linkAttrs set and all the handles in there are closed in either the catch or the finally block. Let me re-phrase the question. Where is the handle closed when the file is not a symbolic link? "h" is not in scope. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2345984248 From duke at openjdk.org Mon Sep 15 12:39:27 2025 From: duke at openjdk.org (serhiysachkov) Date: Mon, 15 Sep 2025 12:39:27 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy Message-ID: This task addresses the restructuring of the test to handle exception, especially during test setup, in a more immediate "fail fast" manner. ------------- Commit messages: - 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy Changes: https://git.openjdk.org/jdk/pull/27294/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27294&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333526 Stats: 56 lines in 1 file changed: 0 ins; 27 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/27294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27294/head:pull/27294 PR: https://git.openjdk.org/jdk/pull/27294 From dfuchs at openjdk.org Mon Sep 15 13:29:01 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 15 Sep 2025 13:29:01 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy In-Reply-To: References: Message-ID: <9tReEk9wGw1Y1Tw0hmSo6QWJpB7E3gCtKScCwCnGP1Y=.34c08333-25fb-4cdf-9bae-3259f0d1216b@github.com> On Mon, 15 Sep 2025 12:32:14 GMT, serhiysachkov wrote: > This task addresses the restructuring of the test to handle exception, especially during test setup, in a more immediate "fail fast" manner. The refactoring looks good generally but why are we explicitely using ports 1122 and 19870? test/jdk/java/nio/channels/DatagramChannel/StressNativeSignal.java line 96: > 94: > 95: public ServerSocketThread() throws IOException { > 96: socket = new ServerSocket(1122); Why are we not using port 0 here? Does this test really need to run on port 1122? I would recommend using port 0, and possibly InetAddress.getLoopbackAddress() (though that's less important since we don't expect anything to connect) test/jdk/java/nio/channels/DatagramChannel/StressNativeSignal.java line 142: > 140: channel = DatagramChannel.open(); > 141: channel.setOption(StandardSocketOptions.SO_RCVBUF, 6553600); > 142: channel.bind(new InetSocketAddress(19870)); Unless using a specific port number is required to trigger the condition being tested, we should bind to port 0 here (and possibly use the loopback too) ------------- PR Review: https://git.openjdk.org/jdk/pull/27294#pullrequestreview-3224582839 PR Review Comment: https://git.openjdk.org/jdk/pull/27294#discussion_r2348984657 PR Review Comment: https://git.openjdk.org/jdk/pull/27294#discussion_r2348988527 From duke at openjdk.org Mon Sep 15 13:41:29 2025 From: duke at openjdk.org (serhiysachkov) Date: Mon, 15 Sep 2025 13:41:29 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy In-Reply-To: <9tReEk9wGw1Y1Tw0hmSo6QWJpB7E3gCtKScCwCnGP1Y=.34c08333-25fb-4cdf-9bae-3259f0d1216b@github.com> References: <9tReEk9wGw1Y1Tw0hmSo6QWJpB7E3gCtKScCwCnGP1Y=.34c08333-25fb-4cdf-9bae-3259f0d1216b@github.com> Message-ID: <3w-s7F9Qx6R-oyjau7lk-QaNdk6kVE73dEzKtIsWMmE=.8b4b8d98-3b58-49db-8886-700dda5f3e0e@github.com> On Mon, 15 Sep 2025 13:23:08 GMT, Daniel Fuchs wrote: >> This task addresses the restructuring of the test to handle exception, especially during test setup, in a more immediate "fail fast" manner. > > test/jdk/java/nio/channels/DatagramChannel/StressNativeSignal.java line 96: > >> 94: >> 95: public ServerSocketThread() throws IOException { >> 96: socket = new ServerSocket(1122); > > Why are we not using port 0 here? Does this test really need to run on port 1122? I would recommend using port 0, and possibly InetAddress.getLoopbackAddress() (though that's less important since we don't expect anything to connect) Didn't change those ports as in a PR that lead to the creation of the ticket, it was discussed(https://github.com/openjdk/jdk/pull/19312) and agreed that no changes require, but if the preferred way is to use port 0 will update the test with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27294#discussion_r2349035898 From duke at openjdk.org Mon Sep 15 14:35:05 2025 From: duke at openjdk.org (serhiysachkov) Date: Mon, 15 Sep 2025 14:35:05 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy [v2] In-Reply-To: References: Message-ID: > This task addresses the restructuring of the test to handle exception, especially during test setup, in a more immediate "fail fast" manner. serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: review comments: changing ports to 0 as requested ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27294/files - new: https://git.openjdk.org/jdk/pull/27294/files/be1f24c1..aa644f58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27294&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27294&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27294/head:pull/27294 PR: https://git.openjdk.org/jdk/pull/27294 From duke at openjdk.org Mon Sep 15 14:35:08 2025 From: duke at openjdk.org (serhiysachkov) Date: Mon, 15 Sep 2025 14:35:08 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy [v2] In-Reply-To: <3w-s7F9Qx6R-oyjau7lk-QaNdk6kVE73dEzKtIsWMmE=.8b4b8d98-3b58-49db-8886-700dda5f3e0e@github.com> References: <9tReEk9wGw1Y1Tw0hmSo6QWJpB7E3gCtKScCwCnGP1Y=.34c08333-25fb-4cdf-9bae-3259f0d1216b@github.com> <3w-s7F9Qx6R-oyjau7lk-QaNdk6kVE73dEzKtIsWMmE=.8b4b8d98-3b58-49db-8886-700dda5f3e0e@github.com> Message-ID: On Mon, 15 Sep 2025 13:38:13 GMT, serhiysachkov wrote: >> test/jdk/java/nio/channels/DatagramChannel/StressNativeSignal.java line 96: >> >>> 94: >>> 95: public ServerSocketThread() throws IOException { >>> 96: socket = new ServerSocket(1122); >> >> Why are we not using port 0 here? Does this test really need to run on port 1122? I would recommend using port 0, and possibly InetAddress.getLoopbackAddress() (though that's less important since we don't expect anything to connect) > > Didn't change those ports as in a PR that lead to the creation of the ticket, it was discussed(https://github.com/openjdk/jdk/pull/19312) and agreed that no changes require, but if the preferred way is to use port 0 will update the test with it. done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27294#discussion_r2349209014 From duke at openjdk.org Mon Sep 15 14:35:11 2025 From: duke at openjdk.org (serhiysachkov) Date: Mon, 15 Sep 2025 14:35:11 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy [v2] In-Reply-To: <9tReEk9wGw1Y1Tw0hmSo6QWJpB7E3gCtKScCwCnGP1Y=.34c08333-25fb-4cdf-9bae-3259f0d1216b@github.com> References: <9tReEk9wGw1Y1Tw0hmSo6QWJpB7E3gCtKScCwCnGP1Y=.34c08333-25fb-4cdf-9bae-3259f0d1216b@github.com> Message-ID: <-DVtZek9bjqKAvvLgnVKaQ2Cz4yAQXSuXWfnnYYm4zo=.d8f4ee7b-7412-45e6-8f60-44649e9257fd@github.com> On Mon, 15 Sep 2025 13:24:24 GMT, Daniel Fuchs wrote: >> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments: changing ports to 0 as requested > > test/jdk/java/nio/channels/DatagramChannel/StressNativeSignal.java line 142: > >> 140: channel = DatagramChannel.open(); >> 141: channel.setOption(StandardSocketOptions.SO_RCVBUF, 6553600); >> 142: channel.bind(new InetSocketAddress(19870)); > > Unless using a specific port number is required to trigger the condition being tested, we should bind to port 0 here (and possibly use the loopback too) done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27294#discussion_r2349209485 From bpb at openjdk.org Mon Sep 15 16:07:14 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 15 Sep 2025 16:07:14 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v6] 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 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 seven additional commits since the last revision: - 8365626: Close handle when breaking for non-link - Merge - 8365626: Close handle if readAttributes() throws - 8365626: Address reviewer comments since previous commit - 8365626: Address reviewer comments since previous commit - 8365626: Incorporate suggestions from review comments - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/82e73a7b..994f07b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=04-05 Stats: 23490 lines in 781 files changed: 12402 ins; 7353 del; 3735 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 Tue Sep 16 07:37:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Sep 2025 07:37:34 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 Sat, 13 Sep 2025 07:16:57 GMT, Alan Bateman wrote: >> attrs.isSymbolicLink() does not throw nor does any other code before the handle is added to the linkAttrs set and all the handles in there are closed in either the catch or the finally block. > > Let me re-phrase the question. Where is the handle closed when the file is not a symbolic link? "h" is not in scope. Now back to the question from a few days ago, is the handle closed if linkAttrs.add(linkAttr) fails and FileSystemLoopException is thrown? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2351241164 From bpb at openjdk.org Tue Sep 16 15:32:55 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Sep 2025 15:32:55 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 Tue, 16 Sep 2025 07:34:46 GMT, Alan Bateman wrote: > [...] is the handle closed if linkAttrs.add(linkAttr) fails and FileSystemLoopException is thrown? I was mistakenly thinking that if the object was not added to the set, then it will have the same handle as one of the objects already in the set, but this is patently untrue. I should check whether two different handles referring to the same file actually end up with equal volume serial numbers and file indexes, which is what one would expect. As to the specific question, I think an explicit CloseHandle is called for here as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2352892215 From bpb at openjdk.org Tue Sep 16 18:15:26 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Sep 2025 18:15:26 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v7] 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: Close out-of-scope handle on loop exception ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/994f07b6..9bc8d4f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=05-06 Stats: 10 lines in 1 file changed: 4 ins; 0 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 alanb at openjdk.org Wed Sep 17 08:02:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 08:02:40 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 Tue, 16 Sep 2025 15:29:56 GMT, Brian Burkhalter wrote: >> Now back to the question from a few days ago, is the handle closed if linkAttrs.add(linkAttr) fails and FileSystemLoopException is thrown? > >> [...] is the handle closed if linkAttrs.add(linkAttr) fails and FileSystemLoopException is thrown? > > I was mistakenly thinking that if the object was not added to the set, then it will have the same handle as one of the objects already in the set, but this is patently untrue. I should check whether two different handles referring to the same file actually end up with equal volume serial numbers and file indexes, which is what one would expect. As to the specific question, I think an explicit CloseHandle is called for here as well. Okay, I think the code is correct now but I worried that the changes to WindowsFileSystemProvider aren't very maintainable. lastLinkAttributes has too many exit paths so very error prone, and isSameFile has too many branches and try/catch.So my preference would be to see some re-work of the change before integrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2354664118 From duke at openjdk.org Wed Sep 17 13:56:00 2025 From: duke at openjdk.org (serhiysachkov) Date: Wed, 17 Sep 2025 13:56:00 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy [v2] In-Reply-To: <9tReEk9wGw1Y1Tw0hmSo6QWJpB7E3gCtKScCwCnGP1Y=.34c08333-25fb-4cdf-9bae-3259f0d1216b@github.com> References: <9tReEk9wGw1Y1Tw0hmSo6QWJpB7E3gCtKScCwCnGP1Y=.34c08333-25fb-4cdf-9bae-3259f0d1216b@github.com> Message-ID: On Mon, 15 Sep 2025 13:26:29 GMT, Daniel Fuchs wrote: > The refactoring looks good generally but why are we explicitely using ports 1122 and 19870? not sure about the original purpose of using specific ports, but it changed to 0 as suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27294#issuecomment-3303116480 From ihse at openjdk.org Wed Sep 17 15:14:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 15:14:16 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc Message-ID: The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). ------------- Commit messages: - Escape # in literals with \ - 8367859: Remove shell script from nio exception gensrc Changes: https://git.openjdk.org/jdk/pull/27338/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367859 Stats: 1058 lines in 11 files changed: 531 ins; 525 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27338/head:pull/27338 PR: https://git.openjdk.org/jdk/pull/27338 From ihse at openjdk.org Wed Sep 17 15:14:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 15:14:16 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). Some implementation notes: I considered writing a Java buildtool to read the existing `exceptions` files, but that seemed like a lot of work to keep up with a format that was not really ideal anyway, but was in fact a shell script snippet, disguised as a data file. The `*.java.template` method aligns better with most other gensrc solutions. This also makes it easier to get a better understanding of how the resulting file will look. As a matter of fact, the generated file with the old solution did not match up with how our files should look. I modified the template to follow this pattern. As an effect of this, all generated files has a diff (in whitespace or comments only) with this code compared to the old, like this: --- ReadOnlyBufferException.java 2025-09-11 11:55:45 +++ NEW/ReadOnlyBufferException.java 2025-09-12 17:40:57 @@ -1,6 +1,5 @@ /* - * Copyright (c) 2000, 2021, Oracle and/or its affiliates. All rights reserved. - * + * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -22,14 +21,10 @@ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. - * */ -// -- This file was mechanically generated: Do not edit! -- // - package java.nio; - /** * Unchecked exception thrown when a content-mutation method such as * put or compact is invoked upon a read-only buffer. @@ -48,5 +43,4 @@ * Constructs an instance of this class. */ public ReadOnlyBufferException() { } - } I consider this an improvement, not a bug. I also discovered a real bug. Due to how the old `exceptions` files were actually shell script snippets that were included and executed, proper care needed to be taken in how to handle quotes. This was not done for `IllegalCharsetNameException.java`. The `"` were eaten by the shell, so the generated Java code was: * legal charset name is used as such. instead of (the intended, and correct) * legal charset name is used as such. That is fixed with this PR. Apart from these changes, the generated files are identical before and after this PR. I don't understand what is going on with GHA. It works perfectly well on my local computer and Oracle's internal CI system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302348906 PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302581306 From ihse at openjdk.org Wed Sep 17 15:14:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 15:14:18 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: <7DZVTx-SNw-JWW4PdDlvpTSU0N7G5E5PKNcoXKYC-Nk=.d6675fe3-c6ce-4e40-85cc-2dedcf9a5cee@github.com> On Wed, 17 Sep 2025 11:36:07 GMT, Magnus Ihse Bursie wrote: > I don't understand what is going on with GHA. It works perfectly well on my local computer and Oracle's internal CI system. The answer to that is "GNU Make 4.3 is going on". I have a tentative fix... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302785629 From alanb at openjdk.org Wed Sep 17 15:28:24 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 15:28:24 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). I really dislike this. Can you please look at putting a template in java.nio.channels and java.nio.charsets for the exceptions in those packages? There will be a naming discussion to have on this too. Same thing for CharsetNameExceptions.java.template. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3303528178 From naoto at openjdk.org Wed Sep 17 16:05:04 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Sep 2025 16:05:04 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:25:44 GMT, Alan Bateman wrote: > Alternatively, maybe we should just check into the exceptions in the src tree and avoid this. @naotoj @bplb, can you provide some opinion on this? I agree. Since those exceptions are not likely to change, It would be easier to maintain just to check-in those generated sources into the repository. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3303661328 From ihse at openjdk.org Wed Sep 17 18:42:01 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 18:42:01 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). I'm glad to hear you say that. That was my initial thinking also, but since it was not done that way originally, I thought it would not be acceptable. I think that is a much better solution. I'll create a new PR with checked-in code, but I'll keep this open for the time being, if it turns out a generated solution is preferred. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304151588 From ihse at openjdk.org Wed Sep 17 19:00:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 19:00:55 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). See https://github.com/openjdk/jdk/pull/27352. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304203859 From bpb at openjdk.org Wed Sep 17 21:01:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Sep 2025 21:01:15 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:02:23 GMT, Naoto Sato wrote: > > Alternatively, maybe we should just check into the exceptions in the src tree and avoid this. @naotoj @bplb, can you provide some opinion on this? > > I agree. Since those exceptions are not likely to change, It would be easier to maintain just to check-in those generated sources into the repository. I concur. Given that the only change since JDK 8 is this 59c59 < * put or compact is invoked upon a read-only buffer." \ --- > * put or compact is invoked upon a read-only buffer." \ these are pretty stable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304544038 From bpb at openjdk.org Wed Sep 17 21:26:35 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Sep 2025 21:26:35 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v8] 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: Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/9bc8d4f4..d3dd257f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=06-07 Stats: 69 lines in 1 file changed: 17 ins; 30 del; 22 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 geliang at kernel.org Thu Sep 18 07:36:58 2025 From: geliang at kernel.org (Geliang Tang) Date: Thu, 18 Sep 2025 15:36:58 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> Message-ID: <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> Hi Alan, On Fri, 2025-09-05 at 18:11 +0800, Geliang Tang wrote: > 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. I have completed the implementation. Thanks to Xiang Gao and Gang Yan for their help. I added a new option named TCP_MPTCPIFY in jdk.net.ExtendedSocketOptions (the name was chosen to align with 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option is set, it calls the JNI function mptcpify0. Following your suggestion, mptcpify0 is implemented by referencing Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP socket, uses dup2 to duplicate it, and then closes the redundant socket. I have added your tag in the patch: Suggested-by: Alan Bateman I also included a test example for this option. All modifications can be found here: https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master Please provide any feedback or suggestions. As for the next steps, should I create a new issue for this feature and submit a proper pull request? Thanks, -Geliang > > 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 alan.bateman at oracle.com Thu Sep 18 11:30:16 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 18 Sep 2025 12:30:16 +0100 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> Message-ID: <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> On 18/09/2025 08:36, Geliang Tang wrote: > I have completed the implementation. Thanks to Xiang Gao and Gang Yan > for their help. I added a new option named TCP_MPTCPIFY in > jdk.net.ExtendedSocketOptions (the name was chosen to align with > 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option is > set, it calls the JNI function mptcpify0. > > Following your suggestion, mptcpify0 is implemented by referencing > Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP socket, > uses dup2 to duplicate it, and then closes the redundant socket. > > I have added your tag in the patch: > > Suggested-by: Alan Bateman > > I also included a test example for this option. All modifications can > be found here: > > https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master > > Please provide any feedback or suggestions. As for the next steps, > should I create a new issue for this feature and submit a proper pull > request? Thanks for confirming that the direction suggested works. This at least demonstrates a feasible direction that does not impact the standard API. As regards next steps then I think start a thread on net-dev to try to get input. I think it would be useful to show potential scenarios where it would be useful and what performance benefits might come from it. I think also useful to talk about whether this is something that an application has to opt into, maybe there are other configuration approaches that would not require application changes? I think it would be useful to discuss testing. If this feature were integrated into the JDK then how would it be tested? Who would test and maintain it? There is a JDK release every 6 months, is someone going test it with each release? If it goes ahead then there the name of the extended socket option and its API docs will need discussion. Details around state will need to be specified, would it be supported to set TCP_MPTCP when bound or connected, does it make sense to ever attempt to set it to false after setting it to true (these are just examples of the details that will need to be specified, they are not important right now). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Thu Sep 18 14:27:25 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 14:27:25 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v8] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Wed, 17 Sep 2025 21:26:35 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: Cleanup src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 471: > 469: try { > 470: h = path.openForReadAttributeAccess(false); > 471: } catch (WindowsException x) { I think you'll need to init h to INVALID_HANDLE_VALUE here or when WindowsException is thrown, otherwise there is a risk that it will be closed twice, assuming I'm reading it correctly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2359590218 From ihse at openjdk.org Thu Sep 18 15:02:01 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 18 Sep 2025 15:02:01 GMT Subject: RFR: 8367859: Remove nio exception gensrc Message-ID: An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. ------------- Commit messages: - Replace tab with spaces - 8367859: Remove nio exception gensrc Changes: https://git.openjdk.org/jdk/pull/27352/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27352&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367859 Stats: 2055 lines in 39 files changed: 1529 ins; 526 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27352/head:pull/27352 PR: https://git.openjdk.org/jdk/pull/27352 From alanb at openjdk.org Thu Sep 18 16:00:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 16:00:53 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. Can you confirm that tier1 + tier2 are passing? (most of the tests are in tier2). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27352#issuecomment-3308284366 From naoto at openjdk.org Thu Sep 18 16:20:33 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Sep 2025 16:20:33 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. charset package changes look good to me src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30: > 28: /** > 29: * Unchecked exception thrown when a string that is not a > 30: * legal charset name is used as such. Could utilize new construct as `{@linkplain Charset##names legal charset name}` ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3240774915 PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360132337 From alanb at openjdk.org Thu Sep 18 16:30:28 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 16:30:28 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:17:24 GMT, Naoto Sato wrote: >> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. > > src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30: > >> 28: /** >> 29: * Unchecked exception thrown when a string that is not a >> 30: * legal charset name is used as such. > > Could utilize new construct as `{@linkplain Charset##names legal charset name}` I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360178485 From bpb at openjdk.org Thu Sep 18 16:33:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Sep 2025 16:33:54 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v8] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Thu, 18 Sep 2025 14:24:52 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8365626: Cleanup > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 471: > >> 469: try { >> 470: h = path.openForReadAttributeAccess(false); >> 471: } catch (WindowsException x) { > > I think you'll need to init h to INVALID_HANDLE_VALUE here or when WindowsException is thrown, otherwise there is a risk that it will be closed twice, assuming I'm reading it correctly. I am probably missing something, but `h` is set to `INVALID_HANDLE_VALUE` before the while-loop is entered and reset to that value at line 486. It is set to a valid value at line 470 unless `openForReadAttributeAccess` throws an exception in which case it will be closed in the finally block. So it can only have a valid value between lines 478 and 484, inclusive. If there is a break or an exception in that line range, then `h` should be closed in the finally block. If there is an exception in the line range 490-491, then `h` will be `INVALID_HANDLE_VALUE` and would not be closed in the finally block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2360192991 From naoto at openjdk.org Thu Sep 18 16:34:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Sep 2025 16:34:55 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:27:50 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30: >> >>> 28: /** >>> 29: * Unchecked exception thrown when a string that is not a >>> 30: * legal charset name is used as such. >> >> Could utilize new construct as `{@linkplain Charset##names legal charset name}` > > I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize. OK fair enough. I just noticed that the file was modified, ie. // -- This file was mechanically generated: Do not edit! -- // was removed, so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360197251 From bpb at openjdk.org Thu Sep 18 16:37:51 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Sep 2025 16:37:51 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v8] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: <9GBrjxyv6SkH0_mpSs54hiNXYRAirKZLTUrIX4uFI3s=.b5b0ece7-a2fa-485a-ad4d-5f27850b689a@github.com> On Thu, 18 Sep 2025 16:31:17 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 471: >> >>> 469: try { >>> 470: h = path.openForReadAttributeAccess(false); >>> 471: } catch (WindowsException x) { >> >> I think you'll need to init h to INVALID_HANDLE_VALUE here or when WindowsException is thrown, otherwise there is a risk that it will be closed twice, assuming I'm reading it correctly. > > I am probably missing something, but `h` is set to `INVALID_HANDLE_VALUE` before the while-loop is entered and reset to that value at line 486. It is set to a valid value at line 470 unless `openForReadAttributeAccess` throws an exception in which case it will be closed in the finally block. So it can only have a valid value between lines 478 and 484, inclusive. If there is a break or an exception in that line range, then `h` should be closed in the finally block. If there is an exception in the line range 490-491, then `h` will be `INVALID_HANDLE_VALUE` and would not be closed in the finally block. Wait, I see. If `FileSystemLoopException` is thrown, then `h` could still be valid. Will change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2360211514 From erikj at openjdk.org Thu Sep 18 16:47:16 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 18 Sep 2025 16:47:16 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3240922142 From alanb at openjdk.org Thu Sep 18 16:54:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 16:54:07 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:32:21 GMT, Naoto Sato wrote: >> I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize. > > OK fair enough. I just noticed that the file was modified, ie. > > // -- This file was mechanically generated: Do not edit! -- // > > was removed, so. Yes, I think that has to be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360284037 From bpb at openjdk.org Thu Sep 18 16:56:04 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Sep 2025 16:56:04 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v8] In-Reply-To: <9GBrjxyv6SkH0_mpSs54hiNXYRAirKZLTUrIX4uFI3s=.b5b0ece7-a2fa-485a-ad4d-5f27850b689a@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <9GBrjxyv6SkH0_mpSs54hiNXYRAirKZLTUrIX4uFI3s=.b5b0ece7-a2fa-485a-ad4d-5f27850b689a@github.com> Message-ID: On Thu, 18 Sep 2025 16:35:10 GMT, Brian Burkhalter wrote: > If `FileSystemLoopException` is thrown, then `h` could still be valid. This is true but it will not have been added to the `linkAttrs` set and so should be closed, so that is correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2360291727 From bpb at openjdk.org Thu Sep 18 17:21:21 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Sep 2025 17:21:21 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: <8OZRZZyc6pyg8QAjOyt-3M_KJ3KF_YwZ-q9SaUmPvvw=.0cf09837-e46c-4da7-8293-a07a82a932f2@github.com> On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. Looks all right. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3241093519 From ihse at openjdk.org Thu Sep 18 17:28:26 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 18 Sep 2025 17:28:26 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:51:47 GMT, Alan Bateman wrote: >> OK fair enough. I just noticed that the file was modified, ie. >> >> // -- This file was mechanically generated: Do not edit! -- // >> >> was removed, so. > > Yes, I think that has to be removed. Alan is right, I just copied in the generated files. This is the files as generated by my previous PR. See this comment https://github.com/openjdk/jdk/pull/27338#issuecomment-3302348906 for details on how they differ. (Apart from a bug fix it is whitespace and comments only). In addition to this, jcheck complained about the generated files containing tabs, so I also had to replace those with spaces. Please go ahead and modernize the code after this PR. :) (But how to do it "yesterday" eludes me ;-)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360419615 From bpb at openjdk.org Thu Sep 18 17:50:02 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Sep 2025 17:50:02 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v8] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <9GBrjxyv6SkH0_mpSs54hiNXYRAirKZLTUrIX4uFI3s=.b5b0ece7-a2fa-485a-ad4d-5f27850b689a@github.com> Message-ID: On Thu, 18 Sep 2025 16:53:24 GMT, Brian Burkhalter wrote: >> Wait, I see. If `FileSystemLoopException` is thrown, then `h` could still be valid. Will change. > >> If `FileSystemLoopException` is thrown, then `h` could still be valid. > > This is true but it will not have been added to the `linkAttrs` set and so should be closed, so that is correct. The variable `h` is set to a valid value by `openForReadAttributeAccess` and reset to invalid if `linkAttrs.add` succeeds. If `add` succeeds, then `h` is in a record added to `linkAttrs` and will be closed at line 507. If `add` fails, then `h` is not added to the set and is closed at line 502. I don't see how it can be closed twice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2360504456 From brian.burkhalter at oracle.com Thu Sep 18 18:08:51 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Sep 2025 18:08:51 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: Message-ID: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> On Sep 17, 2025, at 8:24?AM, Pavel Rappo wrote: FWIW, I too have fallen into this trap, and I did that even more than once. When my brain sees Path.endsWith(String), it somehow silently assumes that its semantic is that of String.endsWith(String). Of course, it isn't. What's worse, I learn about my mistake at runtime. But not because of an exception, no; I learn about it by getting unexpected results. I have filed an issue to improve the specification of this method somehow: https://bugs.openjdk.org/browse/JDK-8368007 There used to be a method that implemented the file extension thingy, but the commit was backed out. If it makes its way back in one form or another, it might help to avoid the trap: One day I might evenutally attempt to push that boulder up the mountain again. Today is not that day. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Sep 18 18:38:07 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Sep 2025 18:38:07 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> Message-ID: <1DC00AEC-810A-4736-8D5F-D77A68144B58@oracle.com> If Path.endsWith(String) and possibly Path.startsWith(String) were to be deprecated, then perhaps something like Path.{start,end}sWIthString(String) could be replacements? Brian On Sep 18, 2025, at 11:19?AM, Rob Spoor wrote: If Path.endsWith(String) and possibly Path.startsWith(String) are deprecated, can we then get Path.endsWithPath(String) and Path.startsWithPath(String) as replacements? Because having to type path.endsWith(path.getFileSystem().getPath(other)) is not only a lot more verbose but my IDE also complains that I don't close the result of calling path.getFileSystem() (which of course I shouldn't), so I have to suppress the warning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Thu Sep 18 18:39:18 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 18:39:18 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v8] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <9GBrjxyv6SkH0_mpSs54hiNXYRAirKZLTUrIX4uFI3s=.b5b0ece7-a2fa-485a-ad4d-5f27850b689a@github.com> Message-ID: On Thu, 18 Sep 2025 17:47:43 GMT, Brian Burkhalter wrote: >>> If `FileSystemLoopException` is thrown, then `h` could still be valid. >> >> This is true but it will not have been added to the `linkAttrs` set and so should be closed, so that is correct. > > The variable `h` is set to a valid value by `openForReadAttributeAccess` and reset to invalid if `linkAttrs.add` succeeds. If `add` succeeds, then `h` is in a record added to `linkAttrs` and will be closed at line 507. If `add` fails, then `h` is not added to the set and is closed at line 502. I don't see how it can be closed twice. Okay, I'll take another pass over this time. I think my main concern is that it has taken many iterations to get lastLinkAttributes right and it's still very fragile. One thing that would help is to add a linkAttributes methods that returns a EntryAttributes if a sym link or null if another file type. That would remove the need for "h" in lastLinkAttributes and remove some of the error paths in this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2360672995 From bpb at openjdk.org Thu Sep 18 18:39:19 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Sep 2025 18:39:19 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v8] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <9GBrjxyv6SkH0_mpSs54hiNXYRAirKZLTUrIX4uFI3s=.b5b0ece7-a2fa-485a-ad4d-5f27850b689a@github.com> Message-ID: On Thu, 18 Sep 2025 18:34:16 GMT, Alan Bateman wrote: > One thing that would help is to add a linkAttributes methods that returns a EntryAttributes if a sym link or null if another file type. I'll see how this would change things. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2360681150 From bpb at openjdk.org Thu Sep 18 21:29:59 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Sep 2025 21:29:59 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v9] In-Reply-To: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: <84BYbj5DsPEri5EJ7ai9_L17vdjnr5zSKiqjsB8E6uo=.065305bc-ff44-44f4-942b-d2db213b7da2@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). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8365626: Further cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/d3dd257f..b30f91f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=07-08 Stats: 73 lines in 1 file changed: 36 ins; 25 del; 12 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 fandreuzzi at openjdk.org Thu Sep 18 22:12:25 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 18 Sep 2025 22:12:25 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user Message-ID: I propose a small patch to skip a tier2 test which fails when it runs as the root user. The test expects an exception when it tries to open a read-only file as `rw`, but this does not happen for the root user. ------------- Commit messages: - skip Changes: https://git.openjdk.org/jdk/pull/27376/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27376&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367988 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27376.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27376/head:pull/27376 PR: https://git.openjdk.org/jdk/pull/27376 From syan at openjdk.org Fri Sep 19 05:58:30 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Sep 2025 05:58:30 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 22:03:09 GMT, Francesco Andreuzzi wrote: > I propose a small patch to skip a tier2 test which fails when it runs as the root user. The test expects an exception when it tries to open a read-only file as `rw`, but this does not happen for the root user. test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 225: > 223: public void readOnlyZipFileFailure() throws IOException { > 224: if (Platform.isRoot()) { > 225: throw new org.testng.SkipException("Test skipped when executed by root user."); Suggestion: throw new SkipException("Test skipped when executed by root user."); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27376#discussion_r2361857304 From fandreuzzi at openjdk.org Fri Sep 19 08:07:12 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 19 Sep 2025 08:07:12 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user [v2] In-Reply-To: References: Message-ID: > I propose a small patch to skip a tier2 test which fails when it runs as the root user. The test expects an exception when it tries to open a read-only file as `rw`, but this does not happen for the root user. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27376/files - new: https://git.openjdk.org/jdk/pull/27376/files/8e356f79..21d104a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27376&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27376&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27376.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27376/head:pull/27376 PR: https://git.openjdk.org/jdk/pull/27376 From fandreuzzi at openjdk.org Fri Sep 19 08:07:14 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 19 Sep 2025 08:07:14 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 05:55:26 GMT, SendaoYan wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> import > > test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 225: > >> 223: public void readOnlyZipFileFailure() throws IOException { >> 224: if (Platform.isRoot()) { >> 225: throw new org.testng.SkipException("Test skipped when executed by root user."); > > Suggestion: > > throw new SkipException("Test skipped when executed by root user."); Thanks, fixed in 21d104a0276bb8e934ed0cd2e567cde414cfde6d ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27376#discussion_r2362112943 From jpai at openjdk.org Fri Sep 19 09:54:10 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Sep 2025 09:54:10 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:07:12 GMT, Francesco Andreuzzi wrote: >> I propose a small patch to skip a tier2 test which fails when it runs as the root user. The test expects an exception when it tries to open a read-only file as `rw`, but this does not happen for the root user. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > import This looks OK to me. I think it might have been better if we had a `@requires` instruction for this, but we don't have that right now. So it's OK to use this construct instead. Please wait a while before integrating - it would be good to hear from Alan @AlanBateman or Brian @bplb if this change is OK. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27376#pullrequestreview-3244083627 From ihse at openjdk.org Fri Sep 19 10:05:20 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Sep 2025 10:05:20 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: <9Ct4IC_vPNBSZ3ynx8D30co9slKicJkZmoSZGel9WC4=.c965130b-6787-4cd7-94c3-1cb2686e6999@github.com> On Thu, 18 Sep 2025 15:58:07 GMT, Alan Bateman wrote: > Can you confirm that tier1 + tier2 are passing? (most of the tests are in tier2). Yes, they pass with flying colors. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27352#issuecomment-3311543989 From ihse at openjdk.org Fri Sep 19 10:08:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Sep 2025 10:08:18 GMT Subject: Withdrawn: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27338 From ihse at openjdk.org Fri Sep 19 10:09:39 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Sep 2025 10:09:39 GMT Subject: Integrated: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. This pull request has now been integrated. Changeset: 65aea485 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/65aea485884134743fbd3da355bd1f861b410704 Stats: 2055 lines in 39 files changed: 1529 ins; 526 del; 0 mod 8367859: Remove nio exception gensrc Reviewed-by: naoto, erikj, bpb ------------- PR: https://git.openjdk.org/jdk/pull/27352 From alanb at openjdk.org Fri Sep 19 11:11:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 19 Sep 2025 11:11:44 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v9] In-Reply-To: <84BYbj5DsPEri5EJ7ai9_L17vdjnr5zSKiqjsB8E6uo=.065305bc-ff44-44f4-942b-d2db213b7da2@github.com> References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <84BYbj5DsPEri5EJ7ai9_L17vdjnr5zSKiqjsB8E6uo=.065305bc-ff44-44f4-942b-d2db213b7da2@github.com> Message-ID: On Thu, 18 Sep 2025 21:29:59 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: Further cleanup It's taken several rounds but I thin the current patch is quite good, just a confusing comment in one method. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 451: > 449: /** > 450: * Returns the attributes of the next symbolic link encountered in the > 451: * specified path. The handle contained in the returned value must be closed I assume the first sentence was copied from lastLinkAttributes whereas it should say that it returns the attributes of the file located by the given path if it's a symbolid link. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27079#pullrequestreview-3244383927 PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2362549822 From bpb at openjdk.org Fri Sep 19 16:10:53 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Sep 2025 16:10:53 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v10] 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: Fix description of linkAttributes method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27079/files - new: https://git.openjdk.org/jdk/pull/27079/files/b30f91f2..9b4d128c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27079&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 Fri Sep 19 16:28:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Sep 2025 16:28:15 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v9] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> <84BYbj5DsPEri5EJ7ai9_L17vdjnr5zSKiqjsB8E6uo=.065305bc-ff44-44f4-942b-d2db213b7da2@github.com> Message-ID: <3kp6T4PgQQDFpATzOtVS93CiqZAMCoFZu2Ml09rsbBc=.c5b226b4-b00b-401e-903f-e84d9e0b8112@github.com> On Fri, 19 Sep 2025 11:06:45 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8365626: Further cleanup > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 451: > >> 449: /** >> 450: * Returns the attributes of the next symbolic link encountered in the >> 451: * specified path. The handle contained in the returned value must be closed > > I assume the first sentence was copied from lastLinkAttributes whereas it should say that it returns the attributes of the file located by the given path if it's a symbolid link. Fixed in [9b4d128](https://github.com/openjdk/jdk/pull/27079/commits/9b4d128cf00552f4032f91f1611738dbbf8133db). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27079#discussion_r2363532486 From alanb at openjdk.org Fri Sep 19 16:37:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 19 Sep 2025 16:37:45 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v10] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Fri, 19 Sep 2025 16:10:53 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: Fix description of linkAttributes method Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27079#pullrequestreview-3245802988 From bpb at openjdk.org Fri Sep 19 17:09:35 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Sep 2025 17:09:35 GMT Subject: RFR: 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) [v10] In-Reply-To: References: <49Fo02MH6vxzylgo-gCRx5WYtETcjoK5DzGlxmqRtB4=.ba8893c4-026b-4493-a5cb-20b31a311792@github.com> Message-ID: On Fri, 19 Sep 2025 16:10:53 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: Fix description of linkAttributes method CI tiers 1-3 passed for penultimate commit b30f91f2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27079#issuecomment-3312994324 From bpb at openjdk.org Fri Sep 19 17:09:36 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Sep 2025 17:09:36 GMT Subject: Integrated: 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). This pull request has now been integrated. Changeset: bca1e6e9 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/bca1e6e9c394508ae7590d2fcb6587c52a644238 Stats: 200 lines in 4 files changed: 147 ins; 17 del; 36 mod 8365626: (fs) Improve handling of broken links in Files.isSameFile() (win) Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/27079 From bpb at openjdk.org Fri Sep 19 22:21:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Sep 2025 22:21:15 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 14:35:05 GMT, serhiysachkov wrote: >> This task addresses the restructuring of the test to handle exception, especially during test setup, in a more immediate "fail fast" manner. > > serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: > > review comments: changing ports to 0 as requested The changes look reasonable to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/27294#pullrequestreview-3247338834 From bpb at openjdk.org Fri Sep 19 22:24:12 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Sep 2025 22:24:12 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 09:50:59 GMT, Jaikiran Pai wrote: > it would be good to hear from Alan @AlanBateman or Brian @bplb if this change is OK I think it looks okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27376#issuecomment-3314013231 From bpb at openjdk.org Fri Sep 19 22:30:14 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Sep 2025 22:30:14 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:07:12 GMT, Francesco Andreuzzi wrote: >> I propose a small patch to skip a tier2 test which fails when it runs as the root user. The test expects an exception when it tries to open a read-only file as `rw`, but this does not happen for the root user. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > import Marked as reviewed by bpb (Reviewer). test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 223: > 221: * read-write mode. > 222: */ > 223: @Test If this test were converted to JUnit 5, then I think [@DisabledIf](https://docs.junit.org/current/api/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIf.html) could be used here. ------------- PR Review: https://git.openjdk.org/jdk/pull/27376#pullrequestreview-3247362550 PR Review Comment: https://git.openjdk.org/jdk/pull/27376#discussion_r2364676894 From duke at openjdk.org Sat Sep 20 06:25:16 2025 From: duke at openjdk.org (duke) Date: Sat, 20 Sep 2025 06:25:16 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:07:12 GMT, Francesco Andreuzzi wrote: >> I propose a small patch to skip a tier2 test which fails when it runs as the root user. The test expects an exception when it tries to open a read-only file as `rw`, but this does not happen for the root user. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > import @fandreuz Your change (at version 21d104a0276bb8e934ed0cd2e567cde414cfde6d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27376#issuecomment-3314628254 From fandreuzzi at openjdk.org Sat Sep 20 06:25:18 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Sat, 20 Sep 2025 06:25:18 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user [v2] In-Reply-To: References: Message-ID: <1V6_HdBxo2yvI3bn_rOzIkYVbrVra97-OnfJBvKqjJs=.ef802f7f-b7a5-45c4-aa09-a9ce04bb7cf3@github.com> On Fri, 19 Sep 2025 22:27:49 GMT, Brian Burkhalter wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> import > > test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 223: > >> 221: * read-write mode. >> 222: */ >> 223: @Test > > If this test were converted to JUnit 5, then I think [@DisabledIf](https://docs.junit.org/current/api/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIf.html) could be used here. I wanted to get rid of this test failure, I'll file a ticket to follow up with conversion to JUnit 5 for this and a couple other adjacent test classes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27376#discussion_r2365347559 From alanb at openjdk.org Sat Sep 20 06:56:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 20 Sep 2025 06:56:14 GMT Subject: RFR: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user [v2] In-Reply-To: <1V6_HdBxo2yvI3bn_rOzIkYVbrVra97-OnfJBvKqjJs=.ef802f7f-b7a5-45c4-aa09-a9ce04bb7cf3@github.com> References: <1V6_HdBxo2yvI3bn_rOzIkYVbrVra97-OnfJBvKqjJs=.ef802f7f-b7a5-45c4-aa09-a9ce04bb7cf3@github.com> Message-ID: On Sat, 20 Sep 2025 06:21:44 GMT, Francesco Andreuzzi wrote: >> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 223: >> >>> 221: * read-write mode. >>> 222: */ >>> 223: @Test >> >> If this test were converted to JUnit 5, then I think [@DisabledIf](https://docs.junit.org/current/api/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIf.html) could be used here. > > I wanted to get rid of this test failure, I'll file a ticket to follow up with conversion to JUnit 5 for this and a couple other adjacent test classes > If this test were converted to JUnit 5, then I think [@DisabledIf](https://docs.junit.org/current/api/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIf.html) could be used here. Yes, or the Assumptions API, both would work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27376#discussion_r2365371202 From fandreuzzi at openjdk.org Sat Sep 20 14:05:28 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Sat, 20 Sep 2025 14:05:28 GMT Subject: Integrated: 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 22:03:09 GMT, Francesco Andreuzzi wrote: > I propose a small patch to skip a tier2 test which fails when it runs as the root user. The test expects an exception when it tries to open a read-only file as `rw`, but this does not happen for the root user. This pull request has now been integrated. Changeset: b03b6f54 Author: Francesco Andreuzzi Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/b03b6f54c5f538146c3088c4dc2cea70ba70d07a Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8367988: NewFileSystemTests.readOnlyZipFileFailure fails when run by root user Reviewed-by: jpai, bpb ------------- PR: https://git.openjdk.org/jdk/pull/27376 From bpb at openjdk.org Mon Sep 22 22:15:32 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 22 Sep 2025 22:15:32 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) Message-ID: Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. ------------- Commit messages: - 8368156: Simplify cleanup of test files - 8368156: java/nio/file/Files/IsSameFile.java failing (win) Changes: https://git.openjdk.org/jdk/pull/27440/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27440&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368156 Stats: 57 lines in 1 file changed: 3 ins; 24 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/27440.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27440/head:pull/27440 PR: https://git.openjdk.org/jdk/pull/27440 From bpb at openjdk.org Mon Sep 22 22:15:32 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 22 Sep 2025 22:15:32 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 22:08:30 GMT, Brian Burkhalter wrote: > Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. The proposed change has so far passed 30 repeats on Linux and Windows. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27440#issuecomment-3321648534 From vyazici at openjdk.org Tue Sep 23 07:17:31 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 23 Sep 2025 07:17:31 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 22:08:30 GMT, Brian Burkhalter wrote: > Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. test/jdk/java/nio/file/Files/IsSameFile.java line 28: > 26: * @summary Test of Files.isSameFile > 27: * @library .. /test/lib > 28: * @build IsSameFile jdk.test.lib.util.FileUtils Test target is not necessary to be included in the `@build`: Suggestion: * @build jdk.test.lib.util.FileUtils test/jdk/java/nio/file/Files/IsSameFile.java line 72: > 70: @BeforeAll > 71: public void init() throws IOException { > 72: Path cwd = Path.of(System.getProperty("user.dir")); There are several places where this idiom is guarded against the absence of the `user.dir` property: Suggestion: Path cwd = Path.of(System.getProperty("user.dir", ".")); I leave it up to you. test/jdk/java/nio/file/Files/IsSameFile.java line 73: > 71: public void init() throws IOException { > 72: Path cwd = Path.of(System.getProperty("user.dir")); > 73: home = Files.createTempDirectory(cwd, "TestISameFile"); Suggestion: home = Files.createTempDirectory(cwd, "TestIsSameFile"); You can also opt for `TestIsSameFile.class.getSimpleName()` to make the code IDE-refactoring-prone. test/jdk/java/nio/file/Files/IsSameFile.java line 87: > 85: } > 86: > 87: public void deleteFiles() throws IOException { I see that `deleteFiles()` is invoked at methods provided to `@MethodSource`s. Maybe you can remove _all_ invocations of `deleteFiles()` and instead simply annotate `deleteFiles()` with `@BeforeEach`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371373199 PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371365589 PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371360925 PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371384327 From alanb at openjdk.org Tue Sep 23 07:56:33 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Sep 2025 07:56:33 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: References: Message-ID: <_vUWouVvwisDPGGTu2iFjupVOZazo_VhCvJgg2gxqVM=.860e15bd-4bef-4e35-8c32-141f0177d8b9@github.com> On Tue, 23 Sep 2025 07:04:25 GMT, Volkan Yazici wrote: >> Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. > > test/jdk/java/nio/file/Files/IsSameFile.java line 72: > >> 70: @BeforeAll >> 71: public void init() throws IOException { >> 72: Path cwd = Path.of(System.getProperty("user.dir")); > > There are several places where this idiom is guarded against the absence of the `user.dir` property: > > Suggestion: > > Path cwd = Path.of(System.getProperty("user.dir", ".")); > > > I leave it up to you. user.dir is a standard property and is required to be set. Defaulting to "." is okay, it just shouldn't happen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371484228 From vyazici at openjdk.org Tue Sep 23 08:13:44 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 23 Sep 2025 08:13:44 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: <_vUWouVvwisDPGGTu2iFjupVOZazo_VhCvJgg2gxqVM=.860e15bd-4bef-4e35-8c32-141f0177d8b9@github.com> References: <_vUWouVvwisDPGGTu2iFjupVOZazo_VhCvJgg2gxqVM=.860e15bd-4bef-4e35-8c32-141f0177d8b9@github.com> Message-ID: On Tue, 23 Sep 2025 07:54:17 GMT, Alan Bateman wrote: > user.dir is a standard property and is required to be set. Defaulting to "." is okay, it just shouldn't happen. If its absence is not expected as you stated, then we should fail if this condition gets violated, IMHO. That is, what @bplb has done is correct ? ignore my remark for the `"."` fallback. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371520150 From jpai at openjdk.org Tue Sep 23 08:13:49 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 23 Sep 2025 08:13:49 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 22:08:30 GMT, Brian Burkhalter wrote: > Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. test/jdk/java/nio/file/Files/IsSameFile.java line 158: > 156: try (FileSystem zipfs = FileSystems.newFileSystem(b)) { > 157: list = new ArrayList(); > 158: list.add(Arguments.of(false, a, zipfs.getPath(b.toString()))); Hello Brian, this returns a collection which contains a `Path` that is obtained from a `FileSystem` that gets closed before the `Path` is used in the test method. Looking at the specification of `FileSystem.getPath()` I don't see any text which states the behaviour of `Path` instances after the `FileSystem` has been closed. I think we would be relying on unspecified behaviour here. Would it be better to refactor this a bit so that the `FileSystem` gets closed after the test(s) are complete? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371521888 From alanb at openjdk.org Tue Sep 23 08:44:29 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Sep 2025 08:44:29 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 08:10:35 GMT, Jaikiran Pai wrote: > Hello Brian, this returns a collection which contains a `Path` that is obtained from a `FileSystem` that gets closed before the `Path` is used in the test method. Looking at the specification of `FileSystem.getPath()` I don't see any text which states the behaviour of `Path` instances after the `FileSystem` has been closed. The FileSystem class description does specify: "Once closed, any further attempt to access objects in the file system cause ClosedFileSystemException to be thrown". I don't have time right now to check that the zip file system adheres to this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371595042 From jpai at openjdk.org Tue Sep 23 09:03:29 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 23 Sep 2025 09:03:29 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 08:41:35 GMT, Alan Bateman wrote: >> test/jdk/java/nio/file/Files/IsSameFile.java line 158: >> >>> 156: try (FileSystem zipfs = FileSystems.newFileSystem(b)) { >>> 157: list = new ArrayList(); >>> 158: list.add(Arguments.of(false, a, zipfs.getPath(b.toString()))); >> >> Hello Brian, this returns a collection which contains a `Path` that is obtained from a `FileSystem` that gets closed before the `Path` is used in the test method. Looking at the specification of `FileSystem.getPath()` I don't see any text which states the behaviour of `Path` instances after the `FileSystem` has been closed. I think we would be relying on unspecified behaviour here. Would it be better to refactor this a bit so that the `FileSystem` gets closed after the test(s) are complete? > >> Hello Brian, this returns a collection which contains a `Path` that is obtained from a `FileSystem` that gets closed before the `Path` is used in the test method. Looking at the specification of `FileSystem.getPath()` I don't see any text which states the behaviour of `Path` instances after the `FileSystem` has been closed. > > The FileSystem class description does specify: "Once closed, any further attempt to access objects in the file system cause ClosedFileSystemException to be thrown". I don't have time right now to check that the zip file system adheres to this. Hello Alan, > I don't have time right now to check that the zip file system adheres to this. I did a quick check. Not all methods on `Path` returned by the ZIP filesystem, adhere to this specification. For example, `toURI()`, `toAbsolutePath()`, `relativize()` all return normally even after the ZIP file system is closed. Whereas, `toRealPath()` throws `ClosedFileSystemException`: jshell> var fs = FileSystems.newFileSystem(java.net.URI.create("jar:file:///tmp/foo.jar"), Map.of()) fs ==> /tmp/foo.jar jshell> var p = fs.getPath("/"); p ==> / jshell> fs.close() jshell> var _ = p.toAbsolutePath() ==> / jshell> var _ = p.toUri() ==> jar:file:///tmp/foo.jar!/ jshell> var _ = p.relativize(p) ==> jshell> var _ = p.toRealPath() | Exception java.nio.file.ClosedFileSystemException | at ZipFileSystem.ensureOpen (ZipFileSystem.java:1843) | at ZipFileSystem.checkAccess (ZipFileSystem.java:584) | at ZipPath.checkAccess (ZipPath.java:885) | at ZipPath.toRealPath (ZipPath.java:176) | at ZipPath.toRealPath (ZipPath.java:56) | at do_it$Aux (#4:1) | at (#4:1) I haven't yet checked other object types returned by the ZipFileSystem, but it does look like it will need some updates to adhere to the specification. I'll take a deeper look and track this separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2371637360 From geliang at kernel.org Tue Sep 23 09:55:15 2025 From: geliang at kernel.org (Geliang Tang) Date: Tue, 23 Sep 2025 17:55:15 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> Message-ID: <2baf027907da32f096cb522691e5d92c454000e4.camel@kernel.org> Hi Alan, Thanks for your reply. On Thu, 2025-09-18 at 12:30 +0100, Alan Bateman wrote: > ? > On 18/09/2025 08:36, Geliang Tang wrote: > ? > > ? > > I have completed the implementation. Thanks to Xiang Gao and Gang > > Yan > > for their help. I added a new option named TCP_MPTCPIFY in > > jdk.net.ExtendedSocketOptions (the name was chosen to align with > > 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option > > is > > set, it calls the JNI function mptcpify0. > > > > Following your suggestion, mptcpify0 is implemented by referencing > > Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP > > socket, > > uses dup2 to duplicate it, and then closes the redundant socket. > > > > I have added your tag in the patch: > > > > Suggested-by: Alan Bateman > > > > I also included a test example for this option. All modifications > > can > > be found here: > > > > https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master > > > > Please provide any feedback or suggestions. As for the next steps, > > should I create a new issue for this feature and submit a proper > > pull > > request? > > ? > ? > ?Thanks for confirming that the direction suggested works. This at > least demonstrates a feasible direction that does not impact the > standard API. > ? > ?As regards next steps then I think start a thread on net-dev to try > to get input. I think it would be useful to show potential scenarios > where it would be useful and what performance benefits might come > from it. I think also useful to talk about whether this is something > that an application has to opt into, maybe there are other > configuration approaches that would not require application changes? > ? > ?I think it would be useful to discuss testing. If this feature were > integrated into the JDK then how would it be tested? Who would test > and maintain it? There is a JDK release every 6 months, is someone > going test it with each release? > ? > ?If it goes ahead then there the name of the extended socket option > and its API docs will need discussion. Details around state will need > to be specified, would it be supported to set TCP_MPTCP when bound or > connected, does it make sense to ever attempt to set it to false > after setting it to true (these are just examples of the details that > will need to be specified, they are not important right now). Following your suggestion, I have started a new thread on net-dev: Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK https://mail.openjdk.org/pipermail/net-dev/2025-September/028085.html Thanks, -Geliang > ? > ?-Alan. > ? > ? From alan.bateman at oracle.com Tue Sep 23 11:09:58 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 23 Sep 2025 12:09:58 +0100 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <2baf027907da32f096cb522691e5d92c454000e4.camel@kernel.org> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> <2baf027907da32f096cb522691e5d92c454000e4.camel@kernel.org> Message-ID: <452654a0-d835-4934-9fd2-8218f63bb5e1@oracle.com> On 23/09/2025 10:55, Geliang Tang wrote: > Following your suggestion, I have started a new thread on net-dev: > > Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK > https://mail.openjdk.org/pipermail/net-dev/2025-September/028085.html > Thanks, let's continue the discussion there. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Tue Sep 23 15:39:01 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 23 Sep 2025 15:39:01 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:12:51 GMT, Volkan Yazici wrote: > Maybe you can remove _all_ invocations of `deleteFiles()` and instead simply annotate `deleteFiles()` with `@BeforeEach`. This will not work. The order of execution is MethodSource - generates stream or arguments BeforeEach Test - tests first argument of stream AfterEach BeforeEach Test - tests second argument of stream AfterEach etc. The `MethodSource` creates all file system objects which are needed by the tests, so if they are deleted in a method annoted `@*Each`, then they will be unavailable for all but the test of the first argument. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2372738965 From bpb at openjdk.org Tue Sep 23 16:07:58 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 23 Sep 2025 16:07:58 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v2] In-Reply-To: References: Message-ID: > Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8368156: Address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27440/files - new: https://git.openjdk.org/jdk/pull/27440/files/407cb87e..7ace52e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27440&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27440&range=00-01 Stats: 17 lines in 1 file changed: 1 ins; 13 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27440.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27440/head:pull/27440 PR: https://git.openjdk.org/jdk/pull/27440 From bpb at openjdk.org Tue Sep 23 16:08:01 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 23 Sep 2025 16:08:01 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:07:37 GMT, Volkan Yazici wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8368156: Address reviewer comments > > test/jdk/java/nio/file/Files/IsSameFile.java line 28: > >> 26: * @summary Test of Files.isSameFile >> 27: * @library .. /test/lib >> 28: * @build IsSameFile jdk.test.lib.util.FileUtils > > Test target is not necessary to be included in the `@build`: > > Suggestion: > > * @build jdk.test.lib.util.FileUtils Neither is `FileUtils`; both removed in 7ace52e. > test/jdk/java/nio/file/Files/IsSameFile.java line 73: > >> 71: public void init() throws IOException { >> 72: Path cwd = Path.of(System.getProperty("user.dir")); >> 73: home = Files.createTempDirectory(cwd, "TestISameFile"); > > Suggestion: > > home = Files.createTempDirectory(cwd, "TestIsSameFile"); > > > You can also opt for `TestIsSameFile.class.getSimpleName()` to make the code IDE-refactoring-prone. Changed as suggested in 7ace52e. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2372809268 PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2372808344 From bpb at openjdk.org Tue Sep 23 16:08:02 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 23 Sep 2025 16:08:02 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v2] In-Reply-To: References: Message-ID: <_VLFIYRK544c-NWnMofXjSDNanDPekBBcmxNdXLVyKI=.b8a70dfa-5098-4c39-ae21-fe92c367fdc2@github.com> On Tue, 23 Sep 2025 08:59:15 GMT, Jaikiran Pai wrote: >>> Hello Brian, this returns a collection which contains a `Path` that is obtained from a `FileSystem` that gets closed before the `Path` is used in the test method. Looking at the specification of `FileSystem.getPath()` I don't see any text which states the behaviour of `Path` instances after the `FileSystem` has been closed. >> >> The FileSystem class description does specify: "Once closed, any further attempt to access objects in the file system cause ClosedFileSystemException to be thrown". I don't have time right now to check that the zip file system adheres to this. > > Hello Alan, > >> I don't have time right now to check that the zip file system adheres to this. > > I did a quick check. Not all methods on `Path` returned by the ZIP filesystem, adhere to this specification. For example, `toURI()`, `toAbsolutePath()`, `relativize()` all return normally even after the ZIP file system is closed. Whereas, `toRealPath()` throws `ClosedFileSystemException`: > > > jshell> var fs = FileSystems.newFileSystem(java.net.URI.create("jar:file:///tmp/foo.jar"), Map.of()) > fs ==> /tmp/foo.jar > > jshell> var p = fs.getPath("/"); > p ==> / > > jshell> fs.close() > > jshell> var _ = p.toAbsolutePath() > ==> / > > jshell> var _ = p.toUri() > ==> jar:file:///tmp/foo.jar!/ > > jshell> var _ = p.relativize(p) > ==> > > jshell> var _ = p.toRealPath() > | Exception java.nio.file.ClosedFileSystemException > | at ZipFileSystem.ensureOpen (ZipFileSystem.java:1843) > | at ZipFileSystem.checkAccess (ZipFileSystem.java:584) > | at ZipPath.checkAccess (ZipPath.java:885) > | at ZipPath.toRealPath (ZipPath.java:176) > | at ZipPath.toRealPath (ZipPath.java:56) > | at do_it$Aux (#4:1) > | at (#4:1) > > I haven't yet checked other object types returned by the ZipFileSystem, but it does look like it will need some updates to adhere to the specification. I'll take a deeper look and track this separately. Code refactored to eliminated any such eventuality in 7ace52e. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2372810549 From bpb at openjdk.org Tue Sep 23 20:33:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 23 Sep 2025 20:33:15 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v3] In-Reply-To: References: Message-ID: > Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8368156: Remove ID from @bug as issue is noreg-self ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27440/files - new: https://git.openjdk.org/jdk/pull/27440/files/7ace52e5..e48d0902 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27440&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27440&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27440.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27440/head:pull/27440 PR: https://git.openjdk.org/jdk/pull/27440 From bpb at openjdk.org Tue Sep 23 23:46:18 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 23 Sep 2025 23:46:18 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 20:33:15 GMT, Brian Burkhalter wrote: >> Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368156: Remove ID from @bug as issue is noreg-self The latest version [e48d090](https://github.com/openjdk/jdk/pull/27440/commits/e48d0902256addac85e1d501db87eab6f0443667) passes on Linux and Windows including on the Windows node where it had been failing at 100%. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27440#issuecomment-3325906590 From vyazici at openjdk.org Wed Sep 24 07:15:15 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 24 Sep 2025 07:15:15 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 20:33:15 GMT, Brian Burkhalter wrote: >> Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368156: Remove ID from @bug as issue is noreg-self Marked as reviewed by vyazici (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27440#pullrequestreview-3261398835 From jpai at openjdk.org Wed Sep 24 14:06:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 24 Sep 2025 14:06:52 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 20:33:15 GMT, Brian Burkhalter wrote: >> Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368156: Remove ID from @bug as issue is noreg-self Thank you Brian, these changes look reasonable to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27440#pullrequestreview-3263098276 From dfuchs at openjdk.org Wed Sep 24 16:03:06 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 24 Sep 2025 16:03:06 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 14:35:05 GMT, serhiysachkov wrote: >> This task addresses the restructuring of the test to handle exception, especially during test setup, in a more immediate "fail fast" manner. > > serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: > > review comments: changing ports to 0 as requested Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27294#pullrequestreview-3263631285 From bpb at openjdk.org Wed Sep 24 18:52:40 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 24 Sep 2025 18:52:40 GMT Subject: RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v3] In-Reply-To: References: Message-ID: <51OMk7FLo1vrNO0LZCOfoHbjXmDNdaDUfjrx-8Vm6Ko=.50f3cc30-a763-414d-9e6f-8d744ed78a79@github.com> On Wed, 24 Sep 2025 14:04:09 GMT, Jaikiran Pai wrote: > Thank you Brian, these changes look reasonable to me. Thanks, @jaikiran and @vy! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27440#issuecomment-3330218327 From bpb at openjdk.org Wed Sep 24 18:52:41 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 24 Sep 2025 18:52:41 GMT Subject: Integrated: 8368156: java/nio/file/Files/IsSameFile.java failing (win) In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 22:08:30 GMT, Brian Burkhalter wrote: > Use try-with-resources to ensure that the FileSystem `zipfs` is closed when no longer needed. This fixes the issue at hand. Other changes are to simplify cleanup of test files. This pull request has now been integrated. Changeset: 4141534e Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/4141534e4a59facf2cd95a799bba7d3c7cf7a1f2 Stats: 67 lines in 1 file changed: 2 ins; 35 del; 30 mod 8368156: java/nio/file/Files/IsSameFile.java failing (win) Reviewed-by: vyazici, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27440 From duke at openjdk.org Thu Sep 25 09:13:43 2025 From: duke at openjdk.org (duke) Date: Thu, 25 Sep 2025 09:13:43 GMT Subject: RFR: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 14:35:05 GMT, serhiysachkov wrote: >> This task addresses the restructuring of the test to handle exception, especially during test setup, in a more immediate "fail fast" manner. > > serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: > > review comments: changing ports to 0 as requested @serhiysachkov Your change (at version aa644f58f9d4e718a4626fe0ab82511a06713f4f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27294#issuecomment-3333018690 From duke at openjdk.org Thu Sep 25 09:54:51 2025 From: duke at openjdk.org (serhiysachkov) Date: Thu, 25 Sep 2025 09:54:51 GMT Subject: Integrated: 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 12:32:14 GMT, serhiysachkov wrote: > This task addresses the restructuring of the test to handle exception, especially during test setup, in a more immediate "fail fast" manner. This pull request has now been integrated. Changeset: 4f4030a4 Author: Serhiy Sachkov Committer: Mark Sheppard URL: https://git.openjdk.org/jdk/commit/4f4030a423d04c8f488d143f0eda4a8de9dbd469 Stats: 57 lines in 1 file changed: 0 ins; 27 del; 30 mod 8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27294 From duke at openjdk.org Thu Sep 25 12:44:33 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 12:44:33 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v15] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: - Merge branch 'openjdk:master' into jdk-8360498 - Removes not needed changes - Revert "Removes not needed changes" This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb. - Removes not needed changes - Removes extra white lines - Merge branch 'pr/25971' into jdk-8360498 - Merge branch 'openjdk:master' into jdk-8158801 - Merge branch 'pr/25971' into jdk-8360498 - Merge branch 'openjdk:master' into jdk-8158801 - Centers missed frames in the middle of screen - ... and 64 more: https://git.openjdk.org/jdk/compare/26b5708c...e5753d14 ------------- Changes: https://git.openjdk.org/jdk/pull/26625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14 Stats: 185 lines in 14 files changed: 96 ins; 44 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From duke at openjdk.org Thu Sep 25 13:03:51 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 13:03:51 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: References: Message-ID: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: Resolves confict for when there is a merge with jdk-8158801 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26625/files - new: https://git.openjdk.org/jdk/pull/26625/files/e5753d14..8794db9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14-15 Stats: 55 lines in 1 file changed: 36 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From alanb at openjdk.org Thu Sep 25 13:30:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Sep 2025 13:30:34 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> References: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> Message-ID: On Thu, 25 Sep 2025 13:03:51 GMT, Khalid Boulanouare wrote: >> This PR will consolidate fixes of the following bugs: >> >> https://bugs.openjdk.org/browse/JDK-8361188 >> https://bugs.openjdk.org/browse/JDK-8361189 >> https://bugs.openjdk.org/browse/JDK-8361190 >> https://bugs.openjdk.org/browse/JDK-8361191 >> https://bugs.openjdk.org/browse/JDK-8361192 >> https://bugs.openjdk.org/browse/JDK-8361193 >> https://bugs.openjdk.org/browse/JDK-8361195 >> >> This PR depends on https://github.com/openjdk/jdk/pull/25971 >> >> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Resolves confict for when there is a merge with jdk-8158801 What is this about? The PR suggests 500+ commits and 300+ files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334044893 From duke at openjdk.org Thu Sep 25 14:00:08 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 14:00:08 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v17] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'openjdk:master' into jdk-8360498 - 8359378: aarch64: crash when using -XX:+UseFPUForSpilling Reviewed-by: aph, rcastanedalo - 8367103: RISC-V: store cpu features in a bitmap Reviewed-by: fyang, luhenry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26625/files - new: https://git.openjdk.org/jdk/pull/26625/files/8794db9a..69c087a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15-16 Stats: 214 lines in 3 files changed: 142 ins; 4 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From duke at openjdk.org Thu Sep 25 14:00:10 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 14:00:10 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: References: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> Message-ID: On Thu, 25 Sep 2025 13:26:46 GMT, Alan Bateman wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Resolves confict for when there is a merge with jdk-8158801 > > What is this about? The PR suggests 500+ commits and 300+ files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists. @AlanBateman This PR is created based on PR https://github.com/openjdk/jdk/tree/pr/25971. My branch https://github.com/kboulanou/jdk/tree/jdk-8360498 is only 2 commits behind master. I am waiting for approval for PR https://github.com/openjdk/jdk/tree/pr/25971 for this PR to follow. Please let me know if there is anything I need to do. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334251324 From myankelevich at openjdk.org Mon Sep 29 10:28:19 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 29 Sep 2025 10:28:19 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v3] In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: > Tests changed in this PR: > 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java > 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java > 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java > 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java > 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java > 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java > 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java > 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java > 12. test/jdk/sun/security/rsa/InvalidBitString.java > 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java > 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java > 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java > > PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) Mikhail Yankelevich has updated the pull request incrementally with 364 additional commits since the last revision: - removed pemrecord usage - 8365190: Remove LockingMode related code from share Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo - 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp Reviewed-by: aboldtch, tschatzl, jwaters - 8360219: [AIX] assert(locals_base >= l2) failed: bad placement Reviewed-by: dlong, mdoerr - 8366864: Sort os/linux includes Reviewed-by: ayang, dholmes - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages Reviewed-by: ayang, shade, stefank, tschatzl - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR) Reviewed-by: vromero - 8365776: Convert JShell tests to use JUnit instead of TestNG Reviewed-by: vromero - 8354871: Replace stack map frame type magics with constants Reviewed-by: liach - 8361533: Apply java.io.Serial annotations in java.logging Reviewed-by: rriggs - ... and 354 more: https://git.openjdk.org/jdk/compare/d44cb277...e0be5eaa ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27194/files - new: https://git.openjdk.org/jdk/pull/27194/files/d44cb277..e0be5eaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=01-02 Stats: 53711 lines in 1891 files changed: 31453 ins; 14034 del; 8224 mod Patch: https://git.openjdk.org/jdk/pull/27194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194 PR: https://git.openjdk.org/jdk/pull/27194 From duke at openjdk.org Tue Sep 30 04:21:00 2025 From: duke at openjdk.org (duke) Date: Tue, 30 Sep 2025 04:21:00 GMT Subject: Withdrawn: 8356127: (fs) UnixFileSystemProvider.implDelete could save a syscall in some cases In-Reply-To: <__DpX8NhzRrLcm-Ev8Z7HovPQqJolMCEcWerlNYvyUg=.9e95dad9-640b-4ebb-9dae-977c216dc3ce@github.com> References: <__DpX8NhzRrLcm-Ev8Z7HovPQqJolMCEcWerlNYvyUg=.9e95dad9-640b-4ebb-9dae-977c216dc3ce@github.com> Message-ID: On Wed, 7 May 2025 21:44:50 GMT, Brian Burkhalter wrote: > Modify `UnixFileSystemProvider.implDelete` to attempt first to delete the file using `unlink` and, if that fails, fall back to using `rmdir` if the file is a directory. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25107