From bpb at openjdk.org Fri Mar 1 00:00:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 1 Mar 2024 00:00:02 GMT Subject: RFR: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files Message-ID: If an `IOException` with message "File too large" is thrown while testing with a large file, then ignore the exception if the type of the `FileStore` where the file would be located is "msdos". ------------- Commit messages: - 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files Changes: https://git.openjdk.org/jdk/pull/18073/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18073&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327096 Stats: 14 lines in 1 file changed: 12 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18073.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18073/head:pull/18073 PR: https://git.openjdk.org/jdk/pull/18073 From gli at openjdk.org Fri Mar 1 07:54:52 2024 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 1 Mar 2024 07:54:52 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order [v3] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 15:03:18 GMT, Pavel Rappo wrote: >> Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback A trivial issue about the name. test/jdk/java/nio/file/Files/StreamTest.java line 78: > 76: static Path[] level1; > 77: static Path[] all; > 78: static Path[] all_followLinks; The name `all_followLinks`, which contains the underline and the lower camel case, is strange. What about `allFollowLinks`? ------------- Changes requested by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18063#pullrequestreview-1910520607 PR Review Comment: https://git.openjdk.org/jdk/pull/18063#discussion_r1508614405 From prappo at openjdk.org Fri Mar 1 09:43:26 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 1 Mar 2024 09:43:26 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order [v4] In-Reply-To: References: Message-ID: > Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Respond to feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18063/files - new: https://git.openjdk.org/jdk/pull/18063/files/5ffccf38..75d1cd01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18063&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18063&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/18063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18063/head:pull/18063 PR: https://git.openjdk.org/jdk/pull/18063 From gli at openjdk.org Fri Mar 1 10:30:52 2024 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 1 Mar 2024 10:30:52 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order [v4] In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 09:43:26 GMT, Pavel Rappo wrote: >> Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback Looks good. ------------- Marked as reviewed by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18063#pullrequestreview-1910817025 From prappo at openjdk.org Fri Mar 1 13:51:55 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 1 Mar 2024 13:51:55 GMT Subject: Integrated: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 12:56:35 GMT, Pavel Rappo wrote: > Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. This pull request has now been integrated. Changeset: 012411ad Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/012411ad8dced3cd1f4ec6e002ebd2d84d2461f5 Stats: 16 lines in 2 files changed: 2 ins; 0 del; 14 mod 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order Reviewed-by: alanb, gli ------------- PR: https://git.openjdk.org/jdk/pull/18063 From bpb at openjdk.org Fri Mar 1 21:48:22 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 1 Mar 2024 21:48:22 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v5] In-Reply-To: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: > Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - 8315273: Re-remove ToRealPath test - Merge - 8315273: Revert ProblemList - Merge - Merge - 8315273: Add bug ID to test - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) ------------- Changes: https://git.openjdk.org/jdk/pull/15525/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15525&range=04 Stats: 149 lines in 3 files changed: 103 ins; 9 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/15525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15525/head:pull/15525 PR: https://git.openjdk.org/jdk/pull/15525 From mbaesken at openjdk.org Wed Mar 6 09:30:54 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Mar 2024 09:30:54 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase Message-ID: We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! ------------- Commit messages: - JDK-8327444 Changes: https://git.openjdk.org/jdk/pull/18132/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18132&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327444 Stats: 113 lines in 16 files changed: 8 ins; 105 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18132/head:pull/18132 PR: https://git.openjdk.org/jdk/pull/18132 From gli at openjdk.org Wed Mar 6 11:00:45 2024 From: gli at openjdk.org (Guoxiong Li) Date: Wed, 6 Mar 2024 11:00:45 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken wrote: > We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! Looks good. Nice refactor. ------------- Marked as reviewed by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1919422137 From alanb at openjdk.org Wed Mar 6 14:15:48 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Mar 2024 14:15:48 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken wrote: > We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! src/java.base/share/native/libjava/jni_util.h line 243: > 241: } while((_result == -1) && (errno == EINTR)); \ > 242: } while(0) > 243: jni_util.h is for all platforms so not the right place for a Unix specific macro. We need think where the right place for this, might have to introduce a jni_util_md.h. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514555111 From mbaesken at openjdk.org Wed Mar 6 14:27:48 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Mar 2024 14:27:48 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 14:13:26 GMT, Alan Bateman wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > src/java.base/share/native/libjava/jni_util.h line 243: > >> 241: } while((_result == -1) && (errno == EINTR)); \ >> 242: } while(0) >> 243: > > jni_util.h is for all platforms so not the right place for a Unix specific macro. We need think where the right place for this, might have to introduce a jni_util_md.h. We could maybe also use the existing https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h - what do you think ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514574059 From alanb at openjdk.org Wed Mar 6 14:35:46 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Mar 2024 14:35:46 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken wrote: > We could maybe also use the existing https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h - what do you think ? jni_md.h goes into the JDK run-time image (for jni.h to include) so I don't think we should be changing that. jni_util.* is JDK internal so I think we're just missing a platform dependent include file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514586726 From mbaesken at openjdk.org Wed Mar 6 15:45:16 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Mar 2024 15:45:16 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v2] In-Reply-To: References: Message-ID: > We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: introduce unix jni_util_md.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18132/files - new: https://git.openjdk.org/jdk/pull/18132/files/014ab1fd..f30a189d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18132&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18132&range=00-01 Stats: 68 lines in 19 files changed: 52 ins; 7 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/18132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18132/head:pull/18132 PR: https://git.openjdk.org/jdk/pull/18132 From alanb at openjdk.org Wed Mar 6 15:51:46 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Mar 2024 15:51:46 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v2] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 15:45:16 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > introduce unix jni_util_md.h src/java.base/aix/native/libnio/ch/Pollset.c line 29: > 27: #include "jni.h" > 28: #include "jni_util.h" > 29: #include "jni_util_md.h" When I suggested jni_util_md.h then I meant create one for Unix and another for Windows, then have jni_util.h include it. This will avoid needing to add an include to all these files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514724921 From mbaesken at openjdk.org Wed Mar 6 16:08:45 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Mar 2024 16:08:45 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v2] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 15:49:05 GMT, Alan Bateman wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> introduce unix jni_util_md.h > > src/java.base/aix/native/libnio/ch/Pollset.c line 29: > >> 27: #include "jni.h" >> 28: #include "jni_util.h" >> 29: #include "jni_util_md.h" > > When I suggested jni_util_md.h then I meant create one for Unix and another for Windows, then have jni_util.h include it. This will avoid needing to add an include to all these files. I considered this too, but the one on Windows would be empty for now -> looks a bit strange . But I can do it why not . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514752727 From mbaesken at openjdk.org Wed Mar 6 16:30:23 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Mar 2024 16:30:23 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: > We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Introduce windows jni_util_md.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18132/files - new: https://git.openjdk.org/jdk/pull/18132/files/f30a189d..2930075d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18132&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18132&range=01-02 Stats: 24 lines in 19 files changed: 1 ins; 22 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18132/head:pull/18132 PR: https://git.openjdk.org/jdk/pull/18132 From clanger at openjdk.org Wed Mar 6 17:21:50 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 6 Mar 2024 17:21:50 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce windows jni_util_md.h Looks good to me modulo a few license year things... src/java.base/macosx/native/libnio/ch/KQueue.c line 2: > 1: /* > 2: * Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved. Here you only change the license year? src/java.base/share/native/libjava/jni_util.h line 30: > 28: > 29: #include "jni.h" > 30: #include "jni_util_md.h" This file needs copyright year update src/java.base/unix/native/libjava/childproc.h line 75: > 73: #define FAIL_FILENO (STDERR_FILENO + 1) > 74: > 75: /* TODO: Refactor. */ Copyright year update missing. src/java.base/unix/native/libnio/ch/nio_util.h line 34: > 32: #include > 33: > 34: #define RESTARTABLE(_cmd, _result) do { \ Copyright year update src/java.base/unix/native/libnio/fs/UnixFileSystem.c line 38: > 36: #include "sun_nio_fs_UnixFileSystem.h" > 37: > 38: #define RESTARTABLE(_cmd, _result) do { \ Copyright year update ------------- Changes requested by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1920355323 PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514867262 PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514873505 PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514876266 PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514878580 PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514878995 From bpb at openjdk.org Wed Mar 6 22:24:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Mar 2024 22:24:14 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v3] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. 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 five additional commits since the last revision: - 8298318: Refine specification of extension; replace addExtension/removeExtension with withExtension/withoutExtension; update test - Merge - 8298318: Correct type in path.getExtension spec - Merge - 8298318: (fs) APIs for handling filename extensions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16226/files - new: https://git.openjdk.org/jdk/pull/16226/files/5a926bdc..b7f00bb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=01-02 Stats: 288681 lines in 6308 files changed: 155902 ins; 95805 del; 36974 mod Patch: https://git.openjdk.org/jdk/pull/16226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16226/head:pull/16226 PR: https://git.openjdk.org/jdk/pull/16226 From bpb at openjdk.org Wed Mar 6 22:25:58 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Mar 2024 22:25:58 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v2] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 23:30:45 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > 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 three additional commits since the last revision: > > - 8298318: Correct type in path.getExtension spec > - Merge > - 8298318: (fs) APIs for handling filename extensions Commit b7f00bb37a99a6ec7c6ff4b2bfa3c914b028925b updates this proposal as follows: 1. `getExtension`: The extension is now considered empty if the prefix of the file name string is a sequence of periods containing the last period instead of if the first character of the file name string is the only period. 2. The `addExtension` and `removeExtension` methods are removed. 3. The `withExtension` and `withoutExtension` methods are added. 4. The `withoutExtension` method has behavior like `removeExtension` but is named so as not to imply modifying an immutable `Path`. 5. The `withExtension` method has behavior like an extension replacement function. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1981936104 From bpb at openjdk.org Wed Mar 6 23:17:56 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Mar 2024 23:17:56 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce windows jni_util_md.h src/java.base/unix/native/libnio/ch/Net.c line 2: > 1: /* > 2: * Copyright (c) 2001, 2024, Oracle and/or its affiliates. All rights reserved. Is the year change needed as it looks like nothing was changed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515273416 From bpb at openjdk.org Wed Mar 6 23:41:05 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Mar 2024 23:41:05 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298318: Remove vestigial trim() call and commented out methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16226/files - new: https://git.openjdk.org/jdk/pull/16226/files/b7f00bb3..caeb1f14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=02-03 Stats: 93 lines in 1 file changed: 0 ins; 92 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16226/head:pull/16226 PR: https://git.openjdk.org/jdk/pull/16226 From gli at openjdk.org Thu Mar 7 03:02:57 2024 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 7 Mar 2024 03:02:57 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce windows jni_util_md.h src/java.base/aix/native/libnio/ch/Pollset.c line 3: > 1: /* > 2: * Copyright (c) 2008, 2024, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2012, 2024 SAP SE. All rights reserved. It seems you only need to update the copyright of the company you work for. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515417217 From dholmes at openjdk.org Thu Mar 7 07:22:54 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Mar 2024 07:22:54 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 03:00:11 GMT, Guoxiong Li wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce windows jni_util_md.h > > src/java.base/aix/native/libnio/ch/Pollset.c line 3: > >> 1: /* >> 2: * Copyright (c) 2008, 2024, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2012, 2024 SAP SE. All rights reserved. > > It seems you only need to update the copyright of the company you work for. Oracle requests/requires that the Oracle copyright always be updated when a file is modified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515660944 From gli at openjdk.org Thu Mar 7 07:32:53 2024 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 7 Mar 2024 07:32:53 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: <3Oc7Dtnp_h7ivbUNx3RvJI1ltC3elMhB6V8Jijp2k_0=.d3081a47-6f3b-4051-8baa-a7254be58293@github.com> On Thu, 7 Mar 2024 07:20:15 GMT, David Holmes wrote: > Oracle requests/requires that the Oracle copyright always be updated when a file is modified. Got it. Thanks for your explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515672685 From alanb at openjdk.org Thu Mar 7 08:11:05 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Mar 2024 08:11:05 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce windows jni_util_md.h Latest version looks good to me. As have been pointed out, there at least 2 files where the copyright header was updated but there are no changes, I assume left over from previous iterations. I assume the RESTARTABLE-close in libattach/VirtualMachineImpl.c will be tracked as a separate issue. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1921724534 From mbaesken at openjdk.org Thu Mar 7 08:16:26 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Mar 2024 08:16:26 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v4] In-Reply-To: References: Message-ID: <5LGbdPzlc3oIQ3TGaN5iglmGa5MCt5YnJzLvE7KUu6s=.b2a22f10-8331-4f15-8a2d-affbef828876@github.com> On Wed, 6 Mar 2024 17:16:03 GMT, Christoph Langer wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust COPYRIGHT year info > > src/java.base/unix/native/libjava/childproc.h line 75: > >> 73: #define FAIL_FILENO (STDERR_FILENO + 1) >> 74: >> 75: /* TODO: Refactor. */ > > Copyright year update missing. Thanks, I updated this too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515719859 From mbaesken at openjdk.org Thu Mar 7 08:16:26 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Mar 2024 08:16:26 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v4] In-Reply-To: References: Message-ID: > We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust COPYRIGHT year info ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18132/files - new: https://git.openjdk.org/jdk/pull/18132/files/2930075d..25a65a71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18132&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18132&range=02-03 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/18132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18132/head:pull/18132 PR: https://git.openjdk.org/jdk/pull/18132 From mbaesken at openjdk.org Thu Mar 7 08:16:26 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Mar 2024 08:16:26 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: <9srUL7ZFMpINp-3Ub6V1mN5RYsiwkPxsQZnET_9sBVk=.3a051bf1-cc2f-47cb-b2f3-d220f32a91ce@github.com> On Wed, 6 Mar 2024 17:14:25 GMT, Christoph Langer wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce windows jni_util_md.h > > src/java.base/share/native/libjava/jni_util.h line 30: > >> 28: >> 29: #include "jni.h" >> 30: #include "jni_util_md.h" > > This file needs copyright year update Agree, updated ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515719458 From mbaesken at openjdk.org Thu Mar 7 08:54:54 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Mar 2024 08:54:54 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 08:08:45 GMT, Alan Bateman wrote: > Latest version looks good to me. As have been pointed out, there at least 2 files where the copyright header was updated but there are no changes, I assume left over from previous iterations. I assume the RESTARTABLE-close in libattach/VirtualMachineImpl.c will be tracked as a separate issue. Yes this was from the commit iterations. The RESTARTABLE-close issue will be tracked here https://bugs.openjdk.org/browse/JDK-8327468 8327468: Do not restart close if errno is EINTR [macOS/linux] Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18132#issuecomment-1982996784 From clanger at openjdk.org Thu Mar 7 09:48:56 2024 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 7 Mar 2024 09:48:56 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v4] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust COPYRIGHT year info Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1921955570 From dholmes at openjdk.org Thu Mar 7 12:06:59 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Mar 2024 12:06:59 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v4] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust COPYRIGHT year info LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1922263102 From bpb at openjdk.org Thu Mar 7 16:25:56 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Mar 2024 16:25:56 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 23:41:05 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Remove vestigial trim() call and commented out methods Intentionally omitted from the recent commit b7f00bb37a99a6ec7c6ff4b2bfa3c914b028925b are: - specialization for Unix using internal `byte[]` representation of path; - conversion of test to JUnit 5. These changes will be made if / when the proposal is otherwise accepted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1983910450 From rriggs at openjdk.org Thu Mar 7 17:02:58 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 7 Mar 2024 17:02:58 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 23:41:05 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Remove vestigial trim() call and commented out methods src/java.base/share/classes/java/nio/file/Path.java line 53: > 51: * {@link #getParent getParent}, {@link #getRoot getRoot}, and {@link #subpath > 52: * subpath} methods to access the path components or a subsequence of its name > 53: * elements, and {@link #getExtension() getExtension} to obtain its extension. Could also mention the other new methods. src/java.base/share/classes/java/nio/file/Path.java line 308: > 306: > 307: /** > 308: * Returns a copy of this {@code Path} with the file name extension removed. Perhaps just `Returns a Path for this Path with the file name extension removed`. That preserves the ability to return `this` if there is no extension. src/java.base/share/classes/java/nio/file/Path.java line 311: > 309: * If this path has no extension, then the path is returned unchanged. > 310: * > 311: *

A compound extension may be replaced by invoking this method and This jumps into compound extension without further describing the single extension case. Perhaps include a simple example. And possibly describe the compound extension case in getExtension(). src/java.base/share/classes/java/nio/file/Path.java line 326: > 324: * assert equals(Path.of(withoutExtension().toString() > 325: * + (getExtension().isEmpty() ? "" : ("." + getExtension()))); > 326: * } This seems more like implSpec text and could be combined with the implSpec. src/java.base/share/classes/java/nio/file/Path.java line 362: > 360: * non-{@linkplain String#isEmpty empty}, and not > 361: * {@linkplain String#isBlank blank}, then a {@code '.'} and then > 362: * {@code extension} are appended to the path returned by Drop "copy" as above. I'd remove the behavior specific to blanks. They are not a good idea but whether they are restricted is the responsibility of the file system, not this APIs. test/jdk/java/nio/file/Path/Extensions.java line 81: > 79: {"compress.gzip", "gzip"}, > 80: {"waitwhat.&$!#%", "&$!#%"}, > 81: {"6.283185307", "283185307"} The behavior of these test cases is good, these are the expected results of getExtension(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516519538 PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516498847 PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516508594 PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516511591 PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516517693 PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516518929 From bpb at openjdk.org Thu Mar 7 17:34:57 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Mar 2024 17:34:57 GMT Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v4] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust COPYRIGHT year info +1 ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1923092889 From bpb at openjdk.org Thu Mar 7 18:32:56 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Mar 2024 18:32:56 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: <1ViK8IUchGK_5FmUqVUDrC-ujqv7WZEAX2aoo-l70k0=.72d5fbc5-7325-4b74-a115-91db443e214c@github.com> On Thu, 7 Mar 2024 16:45:58 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8298318: Remove vestigial trim() call and commented out methods > > src/java.base/share/classes/java/nio/file/Path.java line 308: > >> 306: >> 307: /** >> 308: * Returns a copy of this {@code Path} with the file name extension removed. > > Perhaps just `Returns a Path for this Path with the file name extension removed`. > That preserves the ability to return `this` if there is no extension. Perhaps this? Returns a Path with the same sequence of elements as this Path, but with no extension. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516633268 From duke at openjdk.org Thu Mar 7 20:11:00 2024 From: duke at openjdk.org (Louis Bergelson) Date: Thu, 7 Mar 2024 20:11:00 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v2] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 23:30:45 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > 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 three additional commits since the last revision: > > - 8298318: Correct type in path.getExtension spec > - Merge > - 8298318: (fs) APIs for handling filename extensions I like the idea of adding extension manipulation methods to Path. From my experience, this is an extremely common source of silly bugs. This is very useful for filesystems that have complications around the file name. Things like http urls with query parameters are a consistent source of bugs due to people implementing naive handling of extensions. Letting the individual Path implementation decide what part is the extension would be very helpful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1939344986 From duke at openjdk.org Thu Mar 7 20:35:55 2024 From: duke at openjdk.org (Louis Bergelson) Date: Thu, 7 Mar 2024 20:35:55 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 16:59:54 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8298318: Remove vestigial trim() call and commented out methods > > test/jdk/java/nio/file/Path/Extensions.java line 81: > >> 79: {"compress.gzip", "gzip"}, >> 80: {"waitwhat.&$!#%", "&$!#%"}, >> 81: {"6.283185307", "283185307"} > > The behavior of these test cases is good, these are the expected results of getExtension(). These should probably include some compound extensions as well? ex: "archive.tar.gz" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516786826 From duke at openjdk.org Thu Mar 7 20:35:54 2024 From: duke at openjdk.org (Louis Bergelson) Date: Thu, 7 Mar 2024 20:35:54 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 23:41:05 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Remove vestigial trim() call and commented out methods src/java.base/share/classes/java/nio/file/Path.java line 324: > 322: * This method must satisfy the invariant: > 323: * {@snippet lang="java" : > 324: * assert equals(Path.of(withoutExtension().toString() I'm an author of an HTTP filesystem provider and would like to use these new methods since they address longstanding pain points working with Paths. However, my usage wouldn't be able to satisfy this requirement. Here's an example of on our path strings: `http://example.com/subfolder/file.txt?language=english` In this case, the filename is `file.txt` and the query parameters (`?language=english`) are not considered part of the filename. This invariant doesn't work for such a path. withoutExtension() == "http://example.com/subfolder/file?language=english" getExtension() == "txt" So it would end up looking like: Path.of("http://example.com/subfolder/file?language=english" + ".txt"). == "http://example.com/subfolder/file?language=englis.txt" I think the invariant might be better written something like this: path.equals(path.withExtension(path.getExtension()) As an aside, it's not generally true that `Path.of(path.toString()).equals(path)` so if you are going to require that you have to specify it only applies to the default FileSystemProvider. To construct more general Path implementations you have to use the `Path.of(URI)` method instead of `Path.of(String)` so it would probably be better to refer to that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516785398 From bpb at openjdk.org Thu Mar 7 21:16:55 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Mar 2024 21:16:55 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: <3GQE-KMR_qKGw_TbgvkdkK8aeUa5rq7v5nL6LA6KCpc=.75d35f3b-9d2b-4ba8-a8c2-e74f89dd6509@github.com> On Thu, 7 Mar 2024 20:33:36 GMT, Louis Bergelson wrote: >> test/jdk/java/nio/file/Path/Extensions.java line 81: >> >>> 79: {"compress.gzip", "gzip"}, >>> 80: {"waitwhat.&$!#%", "&$!#%"}, >>> 81: {"6.283185307", "283185307"} >> >> The behavior of these test cases is good, these are the expected results of getExtension(). > > These should probably include some compound extensions as well? ex: "archive.tar.gz" There is already line 75, "foo.tar.gz." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516840878 From lancea at openjdk.org Thu Mar 7 21:19:56 2024 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 7 Mar 2024 21:19:56 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes [v3] In-Reply-To: References: Message-ID: On Sat, 3 Feb 2024 17:28:29 GMT, Eirik Bj?rsn?s wrote: >> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`. >> >> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` >> >> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. >> >> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly. >> >> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. >> >> As a note to reviewers, this PR includes the following intended updates: >> >> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes` >> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` >> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected` >> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs` >> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected` >> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected` >> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method >> - Updated copyright in all affected files >> >> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. >> >> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: >> >> >> make test TEST="test/jdk/java/util/jar" >> make test TEST="test/jdk/java/util/zip" > > Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes > - For clarity, use "externalFileAttributes" instead of "externalAttributes" > - Merge branch 'master' into zipentry-external-attributes > - Update copyright years for 2024 > - Merge branch 'master' into zipentry-external-attributes > - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-1923567034 From bpb at openjdk.org Thu Mar 7 21:25:54 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Mar 2024 21:25:54 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 20:31:55 GMT, Louis Bergelson wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8298318: Remove vestigial trim() call and commented out methods > > src/java.base/share/classes/java/nio/file/Path.java line 324: > >> 322: * This method must satisfy the invariant: >> 323: * {@snippet lang="java" : >> 324: * assert equals(Path.of(withoutExtension().toString() > > I'm an author of an HTTP filesystem provider and would like to use these new methods since they address longstanding pain points working with Paths. However, my usage wouldn't be able to satisfy this requirement. > > Here's an example of on our path strings: `http://example.com/subfolder/file.txt?language=english` > > In this case, the filename is `file.txt` and the query parameters (`?language=english`) are not considered part of the filename. > This invariant doesn't work for such a path. > > withoutExtension() == "http://example.com/subfolder/file?language=english" > getExtension() == "txt" > > So it would end up looking like: > > Path.of("http://example.com/subfolder/file?language=english" + ".txt"). == "http://example.com/subfolder/file?language=englis.txt" > > > I think the invariant might be better written something like this: > > > path.equals(path.withExtension(path.getExtension()) > > > As an aside, it's not generally true that `Path.of(path.toString()).equals(path)`. This is because a `Path.of` always creates a Path from the default filesystem provider. So if you have a Path from an alternate provider and call Path.of(altPath.toString) you get a completely different Path object with a different provider. if you are going to require invariants on the toString behavior you probably have to specify that it only applies to the default FileSystemProvider. > > To construct more general Path implementations you have to use the `Path.of(URI)` method instead of `Path.of(String)` so it would probably be better to refer to that. As for the example "http://example.com/subfolder/file.txt?language=english", this is what I see at present: jshell> Path p = Path.of("http://example.com/subfolder/file.txt?language=english") p ==> http:/example.com/subfolder/file.txt?language=english jshell> p.withoutExtension() $2 ==> http:/example.com/subfolder/file jshell> p.getExtension() $3 ==> "txt?language=english" jshell> p.withoutExtension().toString() + "." + p.getExtension() $4 ==> "http:/example.com/subfolder/file.txt?language=english" jshell> p.withExtension(p.getExtension()) $5 ==> http:/example.com/subfolder/file.txt?language=english The two forms of the invariant appear satisfied. Good point about non-default providers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1516851398 From bpb at openjdk.org Thu Mar 7 22:11:10 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Mar 2024 22:11:10 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v5] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298318: Address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16226/files - new: https://git.openjdk.org/jdk/pull/16226/files/caeb1f14..030a250a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=03-04 Stats: 66 lines in 2 files changed: 37 ins; 16 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16226/head:pull/16226 PR: https://git.openjdk.org/jdk/pull/16226 From bpb at openjdk.org Thu Mar 7 22:46:06 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Mar 2024 22:46:06 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v6] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298318: corretions to commit 030a250aaf4c309d515507527932b233f210501e ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16226/files - new: https://git.openjdk.org/jdk/pull/16226/files/030a250a..4a027a0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=04-05 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16226/head:pull/16226 PR: https://git.openjdk.org/jdk/pull/16226 From mbaesken at openjdk.org Fri Mar 8 08:34:01 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 8 Mar 2024 08:34:01 GMT Subject: Integrated: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken wrote: > We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again ! This pull request has now been integrated. Changeset: fb4610e6 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/fb4610e6b7a339d0a95a99d6e113e3ddda291561 Stats: 185 lines in 18 files changed: 69 ins; 106 del; 10 mod 8327444: simplify RESTARTABLE macro usage in JDK codebase Reviewed-by: gli, clanger, alanb, dholmes, bpb ------------- PR: https://git.openjdk.org/jdk/pull/18132 From eirbjo at openjdk.org Fri Mar 8 09:34:05 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 8 Mar 2024 09:34:05 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes [v4] In-Reply-To: References: Message-ID: <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com> > Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`. > > This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` > > The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. > > To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly. > > While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. > > As a note to reviewers, this PR includes the following intended updates: > > - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes` > - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` > - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected` > - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes` > - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected` > - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected` > - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method > - Updated copyright in all affected files > > If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. > > I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: > > > make test TEST="test/jdk/java/util/jar" > make test TEST="test/jdk/java/util/zip" Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16952/files - new: https://git.openjdk.org/jdk/pull/16952/files/10db9803..243887b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16952.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16952/head:pull/16952 PR: https://git.openjdk.org/jdk/pull/16952 From rriggs at openjdk.org Fri Mar 8 16:34:55 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Mar 2024 16:34:55 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: <2eYe5macx7jja9Lq_MG063WZCFA-OaxtN-mEZYvsu78=.53317446-96ac-4ee4-a70d-e7536a74cd25@github.com> On Thu, 7 Mar 2024 21:23:11 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/file/Path.java line 324: >> >>> 322: * This method must satisfy the invariant: >>> 323: * {@snippet lang="java" : >>> 324: * assert equals(Path.of(withoutExtension().toString() >> >> I'm an author of an HTTP filesystem provider and would like to use these new methods since they address longstanding pain points working with Paths. However, my usage wouldn't be able to satisfy this requirement. >> >> Here's an example of on our path strings: `http://example.com/subfolder/file.txt?language=english` >> >> In this case, the filename is `file.txt` and the query parameters (`?language=english`) are not considered part of the filename. >> This invariant doesn't work for such a path. >> >> withoutExtension() == "http://example.com/subfolder/file?language=english" >> getExtension() == "txt" >> >> So it would end up looking like: >> >> Path.of("http://example.com/subfolder/file?language=english" + ".txt"). == "http://example.com/subfolder/file?language=englis.txt" >> >> >> I think the invariant might be better written something like this: >> >> >> path.equals(path.withExtension(path.getExtension()) >> >> >> As an aside, it's not generally true that `Path.of(path.toString()).equals(path)`. This is because a `Path.of` always creates a Path from the default filesystem provider. So if you have a Path from an alternate provider and call Path.of(altPath.toString) you get a completely different Path object with a different provider. if you are going to require invariants on the toString behavior you probably have to specify that it only applies to the default FileSystemProvider. >> >> To construct more general Path implementations you have to use the `Path.of(URI)` method instead of `Path.of(String)` so it would probably be better to refer to that. > > As for the example "http://example.com/subfolder/file.txt?language=english", this is what I see at present: > > jshell> Path p = Path.of("http://example.com/subfolder/file.txt?language=english") > p ==> http:/example.com/subfolder/file.txt?language=english > > jshell> p.withoutExtension() > $2 ==> http:/example.com/subfolder/file > > jshell> p.getExtension() > $3 ==> "txt?language=english" > > jshell> p.withoutExtension().toString() + "." + p.getExtension() > $4 ==> "http:/example.com/subfolder/file.txt?language=english" > > jshell> p.withExtension(p.getExtension()) > $5 ==> http:/example.com/subfolder/file.txt?language=english > > The two forms of the invariant appear satisfied. > > Good point about non-default providers. I would think that manipulations of filename components of a URI/URL would require extracting/converting to a file path first. Path applies to file system names. One could imagine a FileSystem whose Paths were URIs and then yes it could/should implement the file extension related methods to manipulate the file extension and produce valid URIs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1517957022 From duke at openjdk.org Fri Mar 8 17:32:54 2024 From: duke at openjdk.org (Anthony Vanelverdinghe) Date: Fri, 8 Mar 2024 17:32:54 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v6] In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Mar 8 19:39:54 2024 From: duke at openjdk.org (Louis Bergelson) Date: Fri, 8 Mar 2024 19:39:54 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: <2eYe5macx7jja9Lq_MG063WZCFA-OaxtN-mEZYvsu78=.53317446-96ac-4ee4-a70d-e7536a74cd25@github.com> References: <2eYe5macx7jja9Lq_MG063WZCFA-OaxtN-mEZYvsu78=.53317446-96ac-4ee4-a70d-e7536a74cd25@github.com> Message-ID: <3cNqF1QskP0JkVXi6cDAcUQ2dBdirXKJLVLXnu0Lfao=.4fc8c4ab-14fc-4689-8df5-2db2fe18d92f@github.com> On Fri, 8 Mar 2024 16:32:09 GMT, Roger Riggs wrote: >> As for the example "http://example.com/subfolder/file.txt?language=english", this is what I see at present: >> >> jshell> Path p = Path.of("http://example.com/subfolder/file.txt?language=english") >> p ==> http:/example.com/subfolder/file.txt?language=english >> >> jshell> p.withoutExtension() >> $2 ==> http:/example.com/subfolder/file >> >> jshell> p.getExtension() >> $3 ==> "txt?language=english" >> >> jshell> p.withoutExtension().toString() + "." + p.getExtension() >> $4 ==> "http:/example.com/subfolder/file.txt?language=english" >> >> jshell> p.withExtension(p.getExtension()) >> $5 ==> http:/example.com/subfolder/file.txt?language=english >> >> The two forms of the invariant appear satisfied. >> >> Good point about non-default providers. > > I would think that manipulations of filename components of a URI/URL would require extracting/converting to a file path first. Path applies to file system names. One could imagine a FileSystem whose Paths were URIs and then yes it could/should implement the file extension related methods to manipulate the file extension and produce valid URIs. Yes, our software uses a number of alternative file systems in order to treat file access uniformly across different domains. One for google cloud storage, one for amazon, one for arbitrary http paths, etc. They're constructed using the `Path.of(URI)` mechanism which matches filesystems by URI scheme. I just wanted to point out that invariant around handling of toString() wouldn't hold for non-default implementations of Path so maybe it should be stated more generally in terms of path operations instead of in terms of string concatenation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1518213334 From duke at openjdk.org Fri Mar 8 19:39:54 2024 From: duke at openjdk.org (Louis Bergelson) Date: Fri, 8 Mar 2024 19:39:54 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: <3GQE-KMR_qKGw_TbgvkdkK8aeUa5rq7v5nL6LA6KCpc=.75d35f3b-9d2b-4ba8-a8c2-e74f89dd6509@github.com> References: <3GQE-KMR_qKGw_TbgvkdkK8aeUa5rq7v5nL6LA6KCpc=.75d35f3b-9d2b-4ba8-a8c2-e74f89dd6509@github.com> Message-ID: On Thu, 7 Mar 2024 21:14:42 GMT, Brian Burkhalter wrote: >> These should probably include some compound extensions as well? ex: "archive.tar.gz" > > There is already line 75, "foo.tar.gz." Oops. Sorry about that! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1518216510 From djelinski at openjdk.org Mon Mar 11 09:53:53 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 11 Mar 2024 09:53:53 GMT Subject: RFR: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files In-Reply-To: References: Message-ID: <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com> On Thu, 29 Feb 2024 23:54:42 GMT, Brian Burkhalter wrote: > If an `IOException` with message "File too large" is thrown while testing with a large file, then ignore the exception if the type of the `FileStore` where the file would be located is "msdos". test/jdk/java/nio/channels/FileChannel/Size.java line 87: > 85: FileStore store = p.getFileSystem().provider().getFileStore(p); > 86: if ("msdos".equals(store.type())) // FAT32 > 87: return; // ignore IOE: file too big for 32 bits Throwing a SkippedException might be more appropriate here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18073#discussion_r1519431075 From rriggs at openjdk.org Mon Mar 11 16:34:05 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 11 Mar 2024 16:34:05 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v6] In-Reply-To: References: Message-ID: <1Nb1p69nmPMAKf_qfEqAvW5dKMJqwbDTgUWk4eHeUhY=.5c5fa864-a941-49bc-b6cd-5c79d6aa88e4@github.com> On Fri, 8 Mar 2024 17:30:21 GMT, Anthony Vanelverdinghe wrote: > 1. What is the rationale for `Path.of("..mp3").getExtension()` being equal to `""`? >From my point of view it comes down to whether it is reasonable to consider the string without the extension as the root of a filename of a related file. In this case "." doesn't make sense as the root of file related to ..mp3. The distinction becomes necessary because "." is overloaded, both as a prefix and as an separator. Similarly, does replacing the extension with another string result in the Path of a file that is associated with the original. Given the overloading of ".", it is convenient to consider it a separator between the root and the extension only if the root and extension are not empty. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1988693167 From rriggs at openjdk.org Mon Mar 11 16:34:06 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 11 Mar 2024 16:34:06 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: <3cNqF1QskP0JkVXi6cDAcUQ2dBdirXKJLVLXnu0Lfao=.4fc8c4ab-14fc-4689-8df5-2db2fe18d92f@github.com> References: <2eYe5macx7jja9Lq_MG063WZCFA-OaxtN-mEZYvsu78=.53317446-96ac-4ee4-a70d-e7536a74cd25@github.com> <3cNqF1QskP0JkVXi6cDAcUQ2dBdirXKJLVLXnu0Lfao=.4fc8c4ab-14fc-4689-8df5-2db2fe18d92f@github.com> Message-ID: On Fri, 8 Mar 2024 19:36:15 GMT, Louis Bergelson wrote: >> I would think that manipulations of filename components of a URI/URL would require extracting/converting to a file path first. Path applies to file system names. One could imagine a FileSystem whose Paths were URIs and then yes it could/should implement the file extension related methods to manipulate the file extension and produce valid URIs. > > Yes, our software uses a number of alternative file systems in order to treat file access uniformly across different domains. One for google cloud storage, one for amazon, one for arbitrary http paths, etc. They're constructed using the `Path.of(URI)` mechanism which matches filesystems by URI scheme. I just wanted to point out that invariant around handling of toString() wouldn't hold for non-default implementations of Path so maybe it should be stated more generally in terms of path operations instead of in terms of string concatenation. It make sense to express the behavior in terms of Path though the default implementation needs to be able to take advantage of the mapping between strings and Paths to be able to describe and define the behavior that is consistent across filesystems. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1519870401 From duke at openjdk.org Mon Mar 11 16:41:03 2024 From: duke at openjdk.org (Nizar Benalla) Date: Mon, 11 Mar 2024 16:41:03 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 Message-ID: # Issue - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 I changed the @\since tags to better accurately show when the methods and constructors were introduced. ------------- Commit messages: - fixed @ since tag for Formatter.java class Constructors - fixed @ since tag for Channels.java class newWriter and newReader methods Changes: https://git.openjdk.org/jdk/pull/18032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326853 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From bpb at openjdk.org Mon Mar 11 17:58:53 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Mar 2024 17:58:53 GMT Subject: RFR: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files In-Reply-To: <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com> References: <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com> Message-ID: On Mon, 11 Mar 2024 09:51:01 GMT, Daniel Jeli?ski wrote: >> If an `IOException` with message "File too large" is thrown while testing with a large file, then ignore the exception if the type of the `FileStore` where the file would be located is "msdos". > > test/jdk/java/nio/channels/FileChannel/Size.java line 87: > >> 85: FileStore store = p.getFileSystem().provider().getFileStore(p); >> 86: if ("msdos".equals(store.type())) // FAT32 >> 87: return; // ignore IOE: file too big for 32 bits > > Throwing a SkippedException might be more appropriate here `SkippedException` is EE, no? I think the main question is whether to ignore or throw. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18073#discussion_r1520187108 From djelinski at openjdk.org Mon Mar 11 19:03:17 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 11 Mar 2024 19:03:17 GMT Subject: RFR: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files In-Reply-To: References: <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com> Message-ID: On Mon, 11 Mar 2024 17:56:24 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/channels/FileChannel/Size.java line 87: >> >>> 85: FileStore store = p.getFileSystem().provider().getFileStore(p); >>> 86: if ("msdos".equals(store.type())) // FAT32 >>> 87: return; // ignore IOE: file too big for 32 bits >> >> Throwing a SkippedException might be more appropriate here > > `SkippedException` is EE, no? > > I think the main question is whether to ignore or throw. I was referring to `jtreg.SkippedException`. See: https://openjdk.org/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation If you throw that, the test will still pass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18073#discussion_r1520284094 From djelinski at openjdk.org Mon Mar 11 19:20:16 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 11 Mar 2024 19:20:16 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 23:48:12 GMT, Brian Burkhalter wrote: > Add to the error message of the `IOException` thrown when the `mkfifo` command fails: > > 1. the absolute path of the FIFO which was to have been created; > 2. the text read from the standard error stream of the process in which `mkfifo` was executed. test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java line 137: > 135: } > 136: Process p = Runtime.getRuntime().exec("mkfifo " + fifoFile); > 137: if (p.waitFor() != 0) { use ProcessTools.executeProcess for this; it has facilities to check the exit code and dump process output on failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1520303030 From bpb at openjdk.org Mon Mar 11 20:13:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Mar 2024 20:13:14 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v6] In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 17:30:21 GMT, Anthony Vanelverdinghe wrote: > Why can't `Path::getExtension` be platform or provider dependent as well and specify something as follows? Does this imply not having an extension if the file is hidden, or only ignoring a leading period (`charAt(0) == '.'`) if on UNIX? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1989343925 From bpb at openjdk.org Mon Mar 11 20:13:15 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Mar 2024 20:13:15 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v6] In-Reply-To: References: Message-ID: <0oONdOJMuG5WpoiQ70jDjgPuhyCUtU4-m-j03ZCRGu8=.7e2e51e4-126f-4114-8238-a24fd1e5d4f4@github.com> On Thu, 7 Mar 2024 22:46:06 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: corretions to commit 030a250aaf4c309d515507527932b233f210501e > The invariant effectively says "the extension always comes at the very end of the filename" _and_ "the extension separator is a dot". That is exactly how "extension" has been defined. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1989345988 From bpb at openjdk.org Mon Mar 11 21:48:15 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Mar 2024 21:48:15 GMT Subject: RFR: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files [v2] In-Reply-To: References: <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com> Message-ID: On Mon, 11 Mar 2024 19:00:09 GMT, Daniel Jeli?ski wrote: >> `SkippedException` is EE, no? >> >> I think the main question is whether to ignore or throw. > > I was referring to `jtreg.SkippedException`. See: https://openjdk.org/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation > If you throw that, the test will still pass. So changed in eadd73312dbb2349db94d242e3b08d2d869594d4. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18073#discussion_r1520466860 From bpb at openjdk.org Mon Mar 11 21:48:15 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Mar 2024 21:48:15 GMT Subject: RFR: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files [v2] In-Reply-To: References: Message-ID: <2QIPzuMbsSh7PMFouw5_uco80bECTFk3B6f8X_ghBGo=.f8647c6f-329a-4dcd-81cb-bc6f72d5a657@github.com> > If an `IOException` with message "File too large" is thrown while testing with a large file, then ignore the exception if the type of the `FileStore` where the file would be located is "msdos". Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8327096: Throw SkippedException instead of silently ignoring failure on FAT32 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18073/files - new: https://git.openjdk.org/jdk/pull/18073/files/42c2e315..eadd7331 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18073&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18073&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/18073.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18073/head:pull/18073 PR: https://git.openjdk.org/jdk/pull/18073 From bpb at openjdk.org Mon Mar 11 22:26:25 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Mar 2024 22:26:25 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v2] In-Reply-To: References: Message-ID: > Add to the error message of the `IOException` thrown when the `mkfifo` command fails: > > 1. the absolute path of the FIFO which was to have been created; > 2. the text read from the standard error stream of the process in which `mkfifo` was executed. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8327095: Use ProcessTools ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18072/files - new: https://git.openjdk.org/jdk/pull/18072/files/8ad1bdc1..705bbae4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=00-01 Stats: 12 lines in 1 file changed: 7 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/18072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18072/head:pull/18072 PR: https://git.openjdk.org/jdk/pull/18072 From bpb at openjdk.org Mon Mar 11 22:44:25 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Mar 2024 22:44:25 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v3] In-Reply-To: References: Message-ID: > Add to the error message of the `IOException` thrown when the `mkfifo` command fails: > > 1. the absolute path of the FIFO which was to have been created; > 2. the text read from the standard error stream of the process in which `mkfifo` was executed. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8327095: Improve ProcessTools use ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18072/files - new: https://git.openjdk.org/jdk/pull/18072/files/705bbae4..79b3c50e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/18072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18072/head:pull/18072 PR: https://git.openjdk.org/jdk/pull/18072 From bpb at openjdk.org Mon Mar 11 22:44:25 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Mar 2024 22:44:25 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v3] In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 19:17:08 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8327095: Improve ProcessTools use > > test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java line 137: > >> 135: } >> 136: Process p = Runtime.getRuntime().exec("mkfifo " + fifoFile); >> 137: if (p.waitFor() != 0) { > > use ProcessTools.executeProcess for this; it has facilities to check the exit code and dump process output on failure. See version as of commit 79b3c50e7a32472bcfc5cd8026254257a0d210b0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1520508468 From djelinski at openjdk.org Tue Mar 12 07:14:13 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Mar 2024 07:14:13 GMT Subject: RFR: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files [v2] In-Reply-To: <2QIPzuMbsSh7PMFouw5_uco80bECTFk3B6f8X_ghBGo=.f8647c6f-329a-4dcd-81cb-bc6f72d5a657@github.com> References: <2QIPzuMbsSh7PMFouw5_uco80bECTFk3B6f8X_ghBGo=.f8647c6f-329a-4dcd-81cb-bc6f72d5a657@github.com> Message-ID: On Mon, 11 Mar 2024 21:48:15 GMT, Brian Burkhalter wrote: >> If an `IOException` with message "File too large" is thrown while testing with a large file, then ignore the exception if the type of the `FileStore` where the file would be located is "msdos". > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8327096: Throw SkippedException instead of silently ignoring failure on FAT32 Looks reasonable. Thanks. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18073#pullrequestreview-1930258183 From djelinski at openjdk.org Tue Mar 12 07:39:13 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Mar 2024 07:39:13 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v3] In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 22:44:25 GMT, Brian Burkhalter wrote: >> Add to the error message of the `IOException` thrown when the `mkfifo` command fails: >> >> 1. the absolute path of the FIFO which was to have been created; >> 2. the text read from the standard error stream of the process in which `mkfifo` was executed. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8327095: Improve ProcessTools use test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java line 144: > 142: OutputAnalyzer oa = ProcessTools.executeProcess(pb); > 143: oa.waitFor(); > 144: if (oa.pid() != 0) The test is currently failing for me on WSL1 (Linux configuration), both with and without your changes; presumably NTFS doesn't support FIFO files. Should we fail or skip the test in this case? I'm fine with either, WSL is not a supported build config, and this is not the only failure. If you choose to fail the test, then you can use: ProcessTools.executeProcess(pb).shouldHaveExitValue(0); this will dump the output and throw a RuntimeException for you. If you choose to skip the fifo test instead, `oa.getExitValue()` is what you need here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1520980244 From bpb at openjdk.org Tue Mar 12 16:00:16 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 16:00:16 GMT Subject: RFR: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files [v2] In-Reply-To: References: <2QIPzuMbsSh7PMFouw5_uco80bECTFk3B6f8X_ghBGo=.f8647c6f-329a-4dcd-81cb-bc6f72d5a657@github.com> Message-ID: On Tue, 12 Mar 2024 07:11:40 GMT, Daniel Jeli?ski wrote: > Looks reasonable. Thanks. Thanks for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18073#issuecomment-1991997565 From bpb at openjdk.org Tue Mar 12 16:23:16 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 16:23:16 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v3] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 07:36:45 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8327095: Improve ProcessTools use > > test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java line 144: > >> 142: OutputAnalyzer oa = ProcessTools.executeProcess(pb); >> 143: oa.waitFor(); >> 144: if (oa.pid() != 0) > > The test is currently failing for me on WSL1 (Linux configuration), both with and without your changes; presumably NTFS doesn't support FIFO files. Should we fail or skip the test in this case? I'm fine with either, WSL is not a supported build config, and this is not the only failure. > > If you choose to fail the test, then you can use: > > ProcessTools.executeProcess(pb).shouldHaveExitValue(0); > > this will dump the output and throw a RuntimeException for you. > > If you choose to skip the fifo test instead, `oa.getExitValue()` is what you need here. The `FileStore` type is "NTFS"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1521767442 From bpb at openjdk.org Tue Mar 12 16:35:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 16:35:14 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v3] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 16:20:26 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java line 144: >> >>> 142: OutputAnalyzer oa = ProcessTools.executeProcess(pb); >>> 143: oa.waitFor(); >>> 144: if (oa.pid() != 0) >> >> The test is currently failing for me on WSL1 (Linux configuration), both with and without your changes; presumably NTFS doesn't support FIFO files. Should we fail or skip the test in this case? I'm fine with either, WSL is not a supported build config, and this is not the only failure. >> >> If you choose to fail the test, then you can use: >> >> ProcessTools.executeProcess(pb).shouldHaveExitValue(0); >> >> this will dump the output and throw a RuntimeException for you. >> >> If you choose to skip the fifo test instead, `oa.getExitValue()` is what you need here. > > The `FileStore` type is "NTFS"? > `oa.getExitValue()` is what you need here. Using `oa.pid()` was lame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1521787628 From bpb at openjdk.org Tue Mar 12 17:12:28 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 17:12:28 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v4] In-Reply-To: References: Message-ID: > Add to the error message of the `IOException` thrown when the `mkfifo` command fails: > > 1. the absolute path of the FIFO which was to have been created; > 2. the text read from the standard error stream of the process in which `mkfifo` was executed. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8327095: OutputAnalyzer.pid() -> OutputAnalyzer.getExitValue() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18072/files - new: https://git.openjdk.org/jdk/pull/18072/files/79b3c50e..ea7de7b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18072/head:pull/18072 PR: https://git.openjdk.org/jdk/pull/18072 From djelinski at openjdk.org Tue Mar 12 18:09:13 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Mar 2024 18:09:13 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v3] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 16:32:38 GMT, Brian Burkhalter wrote: >> The `FileStore` type is "NTFS"? > >> `oa.getExitValue()` is what you need here. > > Using `oa.pid()` was lame. `FileStore` type is `drvfs`, which probably stands for "delegated to Windows". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1521916047 From bpb at openjdk.org Tue Mar 12 18:09:18 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 18:09:18 GMT Subject: Integrated: 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 23:54:42 GMT, Brian Burkhalter wrote: > If an `IOException` with message "File too large" is thrown while testing with a large file, then ignore the exception if the type of the `FileStore` where the file would be located is "msdos". This pull request has now been integrated. Changeset: 94b4ed57 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/94b4ed5766381fdb922f9aaba02201a7fb735cb3 Stats: 16 lines in 1 file changed: 13 ins; 1 del; 2 mod 8327096: (fc) java/nio/channels/FileChannel/Size.java fails on partition incapable of creating large files Reviewed-by: djelinski ------------- PR: https://git.openjdk.org/jdk/pull/18073 From bpb at openjdk.org Tue Mar 12 18:12:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 18:12:14 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v3] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 18:06:22 GMT, Daniel Jeli?ski wrote: >>> `oa.getExitValue()` is what you need here. >> >> Using `oa.pid()` was lame. > > `FileStore` type is `drvfs`, which probably stands for "delegated to Windows". I think that means you were in a WSL (Linux) partition. On my system in jshell I think I got that when in `/home/bpb` but got "NTFS" when in `C:\Users\bpb`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1521920067 From bpb at openjdk.org Tue Mar 12 22:09:27 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 22:09:27 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: References: Message-ID: > Add to the error message of the `IOException` thrown when the `mkfifo` command fails: > > 1. the absolute path of the FIFO which was to have been created; > 2. the text read from the standard error stream of the process in which `mkfifo` was executed. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8327095: If mkfifo fails with "Operation not supported", continue with a warning instead of failing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18072/files - new: https://git.openjdk.org/jdk/pull/18072/files/ea7de7b0..0ae84063 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=03-04 Stats: 13 lines in 1 file changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18072/head:pull/18072 PR: https://git.openjdk.org/jdk/pull/18072 From bpb at openjdk.org Tue Mar 12 22:12:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 22:12:14 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v3] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 18:09:53 GMT, Brian Burkhalter wrote: >> `FileStore` type is `drvfs`, which probably stands for "delegated to Windows". > > I think that means you were in a WSL (Linux) partition. On my system in jshell I think I got that when in `/home/bpb` but got "NTFS" when in `C:\Users\bpb`. In 8ad1bdc138590ac52618541175a64d8a477cfc4f I modified the test to to print a warning instead of throwing an exception if `mkfifo` fails due to not being supported on the target file system. This allows most of the test to be executed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1522176291 From bpb at openjdk.org Tue Mar 12 22:57:15 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 22:57:15 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v4] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 17:00:19 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8298318: Remove vestigial trim() call and commented out methods > > src/java.base/share/classes/java/nio/file/Path.java line 53: > >> 51: * {@link #getParent getParent}, {@link #getRoot getRoot}, and {@link #subpath >> 52: * subpath} methods to access the path components or a subsequence of its name >> 53: * elements, and {@link #getExtension() getExtension} to obtain its extension. > > Could also mention the other new methods. Resolved in 030a250aaf4c309d515507527932b233f210501e. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1522215886 From bpb at openjdk.org Tue Mar 12 23:00:45 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 23:00:45 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v7] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298318: Revise handling of leading periods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16226/files - new: https://git.openjdk.org/jdk/pull/16226/files/4a027a0d..f66373e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=05-06 Stats: 39 lines in 2 files changed: 0 ins; 20 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/16226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16226/head:pull/16226 PR: https://git.openjdk.org/jdk/pull/16226 From bpb at openjdk.org Tue Mar 12 23:03:15 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Mar 2024 23:03:15 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v6] In-Reply-To: References: Message-ID: <8xt5LK4UrHSxFQ6FpBY99kpgRLZ_nQmyT8wL51o4SCU=.a58d9b9d-4b9f-4c73-9396-c504a53c2fec@github.com> On Thu, 7 Mar 2024 22:46:06 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: corretions to commit 030a250aaf4c309d515507527932b233f210501e Commit f66373e59318a26393a8efcd869344b3afeac14b makes these changes: 1. `getExtension`: The wording of the specification of what an extension is has been refined, hopefully for the better. 2. `withoutExtension`: The invariant described in the specification has been removed as being redundant with the invariant in the specification of `withExtension`. 3. The test has been updated to match the revised specification. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1992713361 From alanb at openjdk.org Wed Mar 13 07:24:15 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Mar 2024 07:24:15 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: References: Message-ID: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> On Tue, 12 Mar 2024 22:09:27 GMT, Brian Burkhalter wrote: >> Add to the error message of the `IOException` thrown when the `mkfifo` command fails: >> >> 1. the absolute path of the FIFO which was to have been created; >> 2. the text read from the standard error stream of the process in which `mkfifo` was executed. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8327095: If mkfifo fails with "Operation not supported", continue with a warning instead of failing test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java line 157: > 155: } > 156: } > 157: new RandomAccessFile(fifoFile, "rw").close(); Having you looked at using FFM to call mkinfo(2) rather launching a process to run the mkfifo tool? It's very brittle to depend on output like "Operation not supported". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1522655093 From bpb at openjdk.org Wed Mar 13 15:43:13 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 15:43:13 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> References: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> Message-ID: On Wed, 13 Mar 2024 07:21:35 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8327095: If mkfifo fails with "Operation not supported", continue with a warning instead of failing > > test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java line 157: > >> 155: } >> 156: } >> 157: new RandomAccessFile(fifoFile, "rw").close(); > > Having you looked at using FFM to call mkinfo(2) rather launching a process to run the mkfifo tool? It's very brittle to depend on output like "Operation not supported". No, not yet. The test was already launching a process. I would prefer to pursue trying FFM, however, as part of a subsequent, follow-on request rather than in this one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1523504502 From alanb at openjdk.org Wed Mar 13 15:54:16 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Mar 2024 15:54:16 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: References: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> Message-ID: On Wed, 13 Mar 2024 15:40:32 GMT, Brian Burkhalter wrote: > No, not yet. The test was already launching a process. I would prefer to pursue trying FFM, however, as part of a subsequent, follow-on request rather than in this one. I think it would better to not launch a process, it's not needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1523522886 From bpb at openjdk.org Wed Mar 13 16:02:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 16:02:14 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: References: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> Message-ID: <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com> On Wed, 13 Mar 2024 15:51:43 GMT, Alan Bateman wrote: >> No, not yet. The test was already launching a process. I would prefer to pursue trying FFM, however, as part of a subsequent, follow-on request rather than in this one. > >> No, not yet. The test was already launching a process. I would prefer to pursue trying FFM, however, as part of a subsequent, follow-on request rather than in this one. > > I think it would better to not launch a process, it's not needed. I don't disagree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1523536383 From duke at openjdk.org Wed Mar 13 17:37:16 2024 From: duke at openjdk.org (Anthony Vanelverdinghe) Date: Wed, 13 Mar 2024 17:37:16 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v7] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 23:00:45 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Revise handling of leading periods Thanks for the responses/updates. > > Why can't `Path::getExtension` be platform or provider dependent as well and specify something as follows? > > Does this imply not having an extension if the file is hidden, or only ignoring a leading period (`charAt(0) == '.'`) if on UNIX? Only ignoring a leading period (`charAt(0) == '.'`) if on UNIX. The specification would be something like: > The exact definition of file extension is platform or provider dependent. On UNIX for example a file is considered to be hidden if its name begins with a period character ('.') and this interpretation takes precedence over its interpretation as a file extension separator. And I'd add an `@implSpec`/`@implNote` as well: > Providers must/should ignore a leading period character as a file extension separator if and only if they consider a file with a leading period character to be hidden. On another note, please have `withExtension(null)` throw a NullPointerException. `withExtension(ext)`, where ext can be `null`, should instead be written as `withExtension(Optional.ofNullable(ext).orElse(""))` to make it obvious that the treatment of `null` is intentional and not a bug. Similarly, I believe it's worth considering to have `withExtension` throw an IllegalArgumentException if the `extension` parameter starts with a period character: this is almost certainly unintentional (e.g. due to passing on an extension as-is from an API that includes the period character) and a bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1995113255 From bpb at openjdk.org Wed Mar 13 17:40:27 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 17:40:27 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v6] In-Reply-To: References: Message-ID: > Add to the error message of the `IOException` thrown when the `mkfifo` command fails: > > 1. the absolute path of the FIFO which was to have been created; > 2. the text read from the standard error stream of the process in which `mkfifo` was executed. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8327095: Use FFM instead of ProcessTools ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18072/files - new: https://git.openjdk.org/jdk/pull/18072/files/0ae84063..dd7c78e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=04-05 Stats: 38 lines in 1 file changed: 24 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/18072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18072/head:pull/18072 PR: https://git.openjdk.org/jdk/pull/18072 From bpb at openjdk.org Wed Mar 13 17:40:27 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 17:40:27 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com> References: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com> Message-ID: On Wed, 13 Mar 2024 16:00:04 GMT, Brian Burkhalter wrote: >>> No, not yet. The test was already launching a process. I would prefer to pursue trying FFM, however, as part of a subsequent, follow-on request rather than in this one. >> >> I think it would better to not launch a process, it's not needed. > > I don't disagree. Okay I replaced the `ProcessTools` section with FFM in dd7c78e28019659de95df71de2a125b61fa877d3. Should this now remove `othervm` as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1523671744 From bpb at openjdk.org Wed Mar 13 17:53:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 17:53:14 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: References: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com> Message-ID: On Wed, 13 Mar 2024 17:37:17 GMT, Brian Burkhalter wrote: >> I don't disagree. > > Okay I replaced the `ProcessTools` section with FFM in dd7c78e28019659de95df71de2a125b61fa877d3. Should this now remove `othervm` as well? Never mind about `othervm` as it is required for `--enable-native-access`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1523689574 From alanb at openjdk.org Wed Mar 13 19:33:14 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Mar 2024 19:33:14 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: References: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com> Message-ID: On Wed, 13 Mar 2024 17:50:31 GMT, Brian Burkhalter wrote: >> Okay I replaced the `ProcessTools` section with FFM in dd7c78e28019659de95df71de2a125b61fa877d3. Should this now remove `othervm` as well? > > Never mind about `othervm` as it is required for `--enable-native-access`. This looks good but I can't immediately see which platform this part of the test runs on. That is, I assume we don't try to create a fifo on Windows. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1523811851 From bpb at openjdk.org Wed Mar 13 19:33:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 19:33:14 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v5] In-Reply-To: References: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com> <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com> Message-ID: On Wed, 13 Mar 2024 19:27:53 GMT, Alan Bateman wrote: >> Never mind about `othervm` as it is required for `--enable-native-access`. > > This looks good but I can't immediately see which platform this part of the test runs on. That is, I assume we don't try to create a fifo on Windows. If it's running on Windows, `initFile()` returns at line 155 and the `mkfifo()` method is never called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18072#discussion_r1523814588 From rriggs at openjdk.org Wed Mar 13 19:57:19 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 13 Mar 2024 19:57:19 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v7] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 23:00:45 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Revise handling of leading periods The description is intended to have consistent results across different OS and file system types. As written it does not need any specific mention of hidden files and also guards against a file name that does not have a root and only has an extension. The "." is only a separator (for an extension) if non-empty strings come before and after. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1995564126 From bpb at openjdk.org Wed Mar 13 20:17:59 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 20:17:59 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v6] In-Reply-To: <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com> References: <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com> Message-ID: On Wed, 13 Mar 2024 20:13:24 GMT, Alan Bateman wrote: > This looks okay. Thanks. > If it fails sometime then I think we'll need to update it to capture errno. Yes, I did not see immediately how to do that but should figure it out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18072#issuecomment-1995649201 From alanb at openjdk.org Wed Mar 13 20:17:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Mar 2024 20:17:58 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v6] In-Reply-To: References: Message-ID: <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com> On Wed, 13 Mar 2024 17:40:27 GMT, Brian Burkhalter wrote: >> Add to the error message of the `IOException` thrown when the `mkfifo` command fails: >> >> 1. the absolute path of the FIFO which was to have been created; >> 2. the text read from the standard error stream of the process in which `mkfifo` was executed. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8327095: Use FFM instead of ProcessTools This looks okay. If it fails sometime then I think we'll need to update it to capture errno. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18072#pullrequestreview-1935120205 From bpb at openjdk.org Wed Mar 13 20:35:41 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 20:35:41 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v7] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 23:00:45 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Revise handling of leading periods For `withExtension`, throwing a `NullPointerException` if `extension == null` or an `IllegalArgumentExcepion` if the first character of `extension` is a period character seem like good ideas. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1995706449 From bpb at openjdk.org Wed Mar 13 23:12:50 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 23:12:50 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298318: Add parameter checks for withExtension ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16226/files - new: https://git.openjdk.org/jdk/pull/16226/files/f66373e5..8abc295f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=06-07 Stats: 23 lines in 2 files changed: 18 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16226/head:pull/16226 PR: https://git.openjdk.org/jdk/pull/16226 From bpb at openjdk.org Wed Mar 13 23:15:39 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Mar 2024 23:15:39 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8] In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 23:12:50 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Add parameter checks for withExtension Commit 8abc295f4b61aa8ad9cf272a70408042f1ccbcfa changes `withExtension` to: 1. throw a `NullPointerException` if its parameter is `null`; and 2. throw an `IllegalArgumentException` if its parameter is non-`null` and begins with a period character. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1996063320 From alanb at openjdk.org Thu Mar 14 07:07:38 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Mar 2024 07:07:38 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v6] In-Reply-To: References: <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com> Message-ID: On Wed, 13 Mar 2024 20:15:34 GMT, Brian Burkhalter wrote: > Yes, I did not see immediately how to do that but should figure it out. If you look for examples using linker options and captureStateLayout then you should be able to figure it out. I think what you have now is okay, I'm just saying that we'll have to capture errno in the event that the test needs more diagnostic option when mkinfo fails. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18072#issuecomment-1996697057 From maurizio.cimadamore at oracle.com Thu Mar 14 10:04:28 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Mar 2024 10:04:28 +0000 Subject: MMap and hugetlbfs In-Reply-To: References: Message-ID: <58e44637-240f-4c56-ada6-dc0a0c9ebd3e@oracle.com> Hi Cleber, This is more a general question on FileChannel, so I'm adding nio-dev in CC, as someone there might be able to help more. Cheers Maurizio On 13/03/2024 23:09, Cleber Muramoto wrote: > Are there plans to encapsulate offset/page boundary computation in > FileChannel.map for files under a hugetlbfs? > > The problem is that, unlike files in "regular" file systems with 4K > pages, *ftruncate* can only be called with multiples of page size, > otherwise it will fail and set errno to?EINVAL, which is translated in > the JNI land into an IOException with a not very informative message: > "Invalid argument". > > With hugetlbfs, we also have to manually compute page positions, since > FileDispatcher::allocationGranularity() will "always" report 4K and we > have to call *mmap* with, e.g. 2M page alignment: > > ---------- > import static java.nio.file.StandardOpenOption.*; > > import java.io.*; > import java.lang.foreign.*; > import java.nio.channels.*; > import java.nio.channels.FileChannel.*; > import java.nio.file.*; > > public class TestHugeTLBFS { > > ? static final long REGULAR_PS = 4096L; > ? static final long HUGE_PS = 1024 * 1024 * 2L; > ? static final StandardOpenOption[] OPTS = { CREATE, WRITE, READ }; > > ? public static void main(String[] args) throws IOException { > ? ? var base = Paths.get("/var/lib/hugetlbfs/global/pagesize-2MB"); > > ? ? var tmp = Files.createTempFile(base, "test", ".bin"); > > ? ? var a = Arena.ofShared(); > > ? ? MemorySegment ms = null; > > ? ? try (var fc = FileChannel.open(tmp, OPTS)) { > ? ? ? // fails in truncate (length is not a multiple of HUGE_PS) > ? ? ? ms = fc.map(MapMode.READ_WRITE, 0, HUGE_PS - 1, a); > ? ? } catch (IOException e) { > ? ? ? e.printStackTrace(); > ? ? } > > ? ? assert ms == null : "Worked?!"; > > ? ? try (var fc = FileChannel.open(tmp, OPTS)) { > ? ? ? // fails in mmap (computed offset is 4K aligned, but it's not > 2MB aligned) > ? ? ? ms = fc.map(MapMode.READ_WRITE, HUGE_PS + 3 * REGULAR_PS, > HUGE_PS - 3 * REGULAR_PS, a); > ? ? } catch (IOException e) { > ? ? ? e.printStackTrace(); > ? ? } > > ? ? assert ms == null : "Worked?!"; > > ? ? try (var fc = FileChannel.open(tmp, OPTS)) { > ? ? ? // This works, because the aligned offset ends up 2MB aligned > ? ? ? ms = fc.map(MapMode.READ_WRITE, HUGE_PS + 19, HUGE_PS -? 19, a); > ? ? } catch (IOException e) { > ? ? ? throw new UncheckedIOException(e); > ? ? } > > ? ? ms.set(ValueLayout.JAVA_INT_UNALIGNED, 0, 42); > ? ? a.close(); > > ? ? try (var fc = FileChannel.open(tmp, OPTS)) { > ? ? ? ms = fc.map(MapMode.READ_WRITE, HUGE_PS + 19 , HUGE_PS - 19, a = > Arena.ofShared()); > ? ? } catch (IOException e) { > ? ? ? throw new UncheckedIOException(e); > ? ? } > > ? ? assert ms.get(ValueLayout.JAVA_INT_UNALIGNED, 0) == 42; > ? ? a.close(); > ? } > } > ---------- > > To satisfy the alignment constraints for both offset and length, the > offset has to be rounded down to the beginning of a page boundary and > the length must be compensated taking into account the aligned start > offset, more or less like: > > MemorySegment map(Path path, long offset, long length, long pageSize) { > ? ? var start = offset; > ? ? var len = length; > ? ? var truncLen = start + len; > > ? ? if (truncLen % pageSize != 0) { > ? ? ? // round down to start of a page offset -> offset - (offset % > pageSize) > ? ? ? start = alignDown(offset, pageSize); > ? ? ? var end = offset + length; > ? ? ? len = end - start; > ? ? ? truncLen = start + len; > > ? ? ? if (truncLen % pageSize != 0) { > ? ? ? ? // round up to a multiple of pageSize: length -> pageSize * > (length / pageSize + ((length % pageSize == 0) ? 0 : 1)) > ? ? ? ? len = alignUp(len, pageSize); > ? ? ? ? truncLen = start + len; > > ? ? ? ? assert truncLen % pageSize == 0 : "Sanity"; > ? ? ? } > ? ? } > > ? ? try (var fc = FileChannel.open(path,...)) { > ? ? ? var segment = fc.map(mode, path, start, len, Arena.ofSomething()); > > ? ? ? if (start != offset || len != length) { > ? ? ? ? segment = segment.asSlice(offset - start, length); > ? ? ? } > > ? ? ? return segment; > ? ? } > } > > It would be nice to have this somehow handled by FileChannel. > > An overload with a user-defined page size might not be ideal, but it > might be the cheapest way to bypass the (incorrect) > FileDispatcher::allocationGranularity() value to enforce correct > alignment constraints. > > Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Thu Mar 14 15:53:44 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 14 Mar 2024 15:53:44 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails [v6] In-Reply-To: References: <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com> Message-ID: On Thu, 14 Mar 2024 07:05:15 GMT, Alan Bateman wrote: > If you look for examples using linker options and captureStateLayout then you should be able to figure it out. I found some documentation at https://docs.oracle.com/en/java/javase/21/core/checking-native-errors-using-errno.html#GUID-BBB64F4A-A68C-4E70-BFCA-B9984D7D3C47 but I think it can wait until needed, as you say. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18072#issuecomment-1997772490 From bpb at openjdk.org Thu Mar 14 15:53:45 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 14 Mar 2024 15:53:45 GMT Subject: Integrated: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 23:48:12 GMT, Brian Burkhalter wrote: > Add to the error message of the `IOException` thrown when the `mkfifo` command fails: > > 1. the absolute path of the FIFO which was to have been created; > 2. the text read from the standard error stream of the process in which `mkfifo` was executed. This pull request has now been integrated. Changeset: debd5973 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/debd59732de2b865bbe81710debcae237e3f135b Stats: 42 lines in 1 file changed: 36 ins; 4 del; 2 mod 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/18072 From duke at openjdk.org Thu Mar 14 17:38:41 2024 From: duke at openjdk.org (Anthony Vanelverdinghe) Date: Thu, 14 Mar 2024 17:38:41 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8] In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 23:12:50 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Add parameter checks for withExtension Let me summarize. For `getExtension` there's: > whether to include the period I'm happy to be proven wrong, but I hold that including it is a prerequisite for intuitive behavior in all cases. For example, both `Path.of("test.").withoutExtension().withExtension("txt")` and `Path.of("test.").withExtension("txt")` actually result in `test..txt`, whereas I expect these to result in `test.txt`. and there's: > how to define file extension 1. platform and/or provider dependent (matches 2 or 3, depending on the platform and/or provider) * pro: intuitive behavior on all platforms * con: not consistent across all platforms 2. "anything past the last period, if any, the empty string otherwise" (matches all common Java APIs, Windows, ...) * pro: trivial definition * pro: compatible with all common Java APIs (`Files::probeContentType`, Guava, Apache Commons) * pro: Windows "owns" the concept of file extension, in the sense that it actually extensively relies on file extensions in its treatment of files. So if 1 global definition must be chosen, it makes sense to adopt the one of the platform that "owns" it 3. "anything past the last period, if any and if it is not the first character of the file name, the empty string otherwise" (matches UNIX, ...) * pro: intuitive behavior on UNIX * con: "if it is not the first character of the file name" cannot be intuitively justified without mentioning the UNIX-specific way of marking a path as hidden * it might be motivated by introducing the concept of a file "root" and requiring the root to be non-empty, but "root" is an artificial construct and both Windows and UNIX actually allow empty roots (for UNIX this can't be proven, but it also can't be disproven) * note that this is actually a pro if this option is considered in the context of `1.` 4. "anything past the last period, if any and if it is not the first character of the file name and if it is not preceded by nothing but dots, the empty string otherwise" (matches Python, Ruby) * con: very uncommon definition * con: "if it is not preceded by nothing but dots" is an arbitrary condition Personally I prefer `1.`. I agree that consistency across providers is a worthwhile goal though (e.g. to have `jdk.zipfs` be consistent with the default provider). So I'd implement `getExtension` as follows in Path itself, and override it in `WindowsPath` (implementing `2.`) and `UnixPath` (implementing `3.`): default String getExtension() { // avoid StackOverflowError if(/* java.nio.file.spi.DefaultFileSystemProvider is specified and this path is an instance of the specified default provider */) { // implement `2.` } else { return Path.of(getFileName()).getExtension(); } } If consistency across all platforms and providers is a must, I'm advocating for `2.` for the reasons mentioned above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1997990007 From bpb at openjdk.org Fri Mar 15 01:45:40 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 15 Mar 2024 01:45:40 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8] In-Reply-To: References: Message-ID: <8lOBzECjbca5-r9I8jyhVua_BGz6VzQradze3rzKXoY=.6bc9c9ea-cefc-46d2-b64c-3dc965c4888d@github.com> On Wed, 13 Mar 2024 23:12:50 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Add parameter checks for withExtension The approach we have taken is, firstly, to consider the last period character in the file name, if present, to be a separator only. As such it has no value as part of any name. All periods but this last in the name are treated as regular characters with no special meaning. Secondly, for an extension to have any significance, there must be a root or base of the file name, meaning that the part before the last period must be non-empty. This approach appears to be consistent across all platforms and providers. Whether the file is hidden is irrelevant. For the cited case `"test."`, the period is part of the file name, and so both `Path.of("test.").withoutExtension().withExtension("txt")` and `Path.of("test.").withExtension("txt")` _should_ result in `test..txt`: the first `.` is part of the file name and the last is a separator. Likewise, both `Path.of("test..dat").withoutExtension().withExtension("txt")` and `Path.of("test..dat").withExtension("txt")` both yield `test..txt`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1998756900 From duke at openjdk.org Fri Mar 15 11:34:48 2024 From: duke at openjdk.org (Nizar Benalla) Date: Fri, 15 Mar 2024 11:34:48 GMT Subject: RFR: JDK-8326951 Missing @since Tags Message-ID: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class ------------- Commit messages: - fix rest of private/public since tags - fix PrintStream:write:(byte[]) since tag - Merge branch 'openjdk:master' into add-missing-since-tags - added missing @ since tags to multiple methods and constructors following bug report JDK-8326951 Changes: https://git.openjdk.org/jdk/pull/18055/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326951 Stats: 19 lines in 17 files changed: 7 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055 PR: https://git.openjdk.org/jdk/pull/18055 From duke at openjdk.org Fri Mar 15 11:34:49 2024 From: duke at openjdk.org (Nizar Benalla) Date: Fri, 15 Mar 2024 11:34:49 GMT Subject: RFR: JDK-8326951 Missing @since Tags In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> Message-ID: On Thu, 29 Feb 2024 09:45:35 GMT, Nizar Benalla wrote: > I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class `/covered` ------------- PR Comment: https://git.openjdk.org/jdk/pull/18055#issuecomment-1988621229 From duke at openjdk.org Fri Mar 15 13:30:07 2024 From: duke at openjdk.org (zde) Date: Fri, 15 Mar 2024 13:30:07 GMT Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes MaxDirectMemorySize overflow [v6] In-Reply-To: References: Message-ID: On Tue, 19 Sep 2023 20:03:57 GMT, Brian Burkhalter wrote: >> `ByteArrayInputStream.transferTo` invoked with an `OutputStream` parameter which delegates to a `FileChannel` throws an `OutOfMemoryError` if the length of the `byte[]` wrapped by the `ByteArrayInputStream` exceeds `MaxDirectMemorySize`. This is because `FileChannel.write` uses `IOUtil.write` which creates a temporary direct buffer for writing. If the `byte[]` length is larger than `MaxDirectMemorySize`, then the temporary direct buffer allocation fails with an `OutOfMemoryError`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8316156: Revert BufferedInputStream changes; update test > because FileChannel.write uses IOUtil.write which creates a temporary direct buffer for writing Why are you "fixing" `ByteArrayInputStream.writeTo` when the problem is elsewhere? `IOUtil.write` should create a reasonably sized buffer and reuse it instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1999658309 From duke at openjdk.org Sat Mar 16 22:23:24 2024 From: duke at openjdk.org (Anthony Vanelverdinghe) Date: Sat, 16 Mar 2024 22:23:24 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8] In-Reply-To: References: Message-ID: <8E5VOdhiIyY6BzHE44QEi6i_2eK8oMKbgTauVBRmqrY=.3ed2a7e3-b9fb-42c1-965a-13280c98ec59@github.com> On Wed, 13 Mar 2024 23:12:50 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298318: Add parameter checks for withExtension Thanks for bearing with me and detailing the rationale. What I still fail to grasp, is why consistent behavior across platforms and providers is a must. This PR demonstrates that there's simply no such thing as *the* definition of file extension and most of the `java.nio.file` APIs already exhibit non-portable behavior in one way or the other: the related `Files::probeContentType` isn't consistent across platforms, most APIs don't allow mixing Paths from different providers, creating a path on UNIX by passing in a Windows path (`Path.of("foo\\bar")`) will give an unexpected result, `Files.copy(zipEntry, extractedFile)` will return `false` for `Files.isHidden(zipEntry)` while it might return `true` for `Files.isHidden(extractedFile)`, ... On another note, is the intention to specify "if there's no debate possible, we return the file extension. Otherwise, we return the empty string"? If so, I believe the return type ought to be `Optional`. That way `text` could return `Optional.of("")` whereas `text.` would return `Optional.empty()`. And then I could do `file.getExtension().or(treatEdgeCases)` to treat edge cases as appropriate for my use case. If not, and the intention really is to specify that neither `.mp3` nor `test.` have a file extension and that > for an extension to have any significance, there must be a root or base of the file name then I find this problematic, because this assertion is simply not true: on Windows, extensions are always significant and on UNIX, files with an empty root can't be created due to the "hidden marker"-meaning taking precedence over the "file extension"-meaning. In other words: I'm not aware of any platform where this assertion can be demonstrated to be true. On a final note, I think the implementation for `1.` in my previous comment is actually a pretty good compromise: it retains the current minimalistic API, ensures consistent behavior across providers (unless overridden of course, but the current API has the same issue), and it allows developers to set their own provider in order to implement the API as desired (e.g. I could implement a provider which, for `Path.of(".mp3")` returns either `mp3` or `""`, depending on whether the file is located on an NTFS filesystem or not). `getExtension` would then just be specified in the same vein as `Files::isHidden` and the invariant would be as generic as possible: `getExtension().equalsIgnoreCase(withoutExtension().withExtension(getExtension()).getExtension())`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-2000190223 From duke at openjdk.org Sat Mar 16 22:23:33 2024 From: duke at openjdk.org (ExE Boss) Date: Sat, 16 Mar 2024 22:23:33 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8] In-Reply-To: <8E5VOdhiIyY6BzHE44QEi6i_2eK8oMKbgTauVBRmqrY=.3ed2a7e3-b9fb-42c1-965a-13280c98ec59@github.com> References: <8E5VOdhiIyY6BzHE44QEi6i_2eK8oMKbgTauVBRmqrY=.3ed2a7e3-b9fb-42c1-965a-13280c98ec59@github.com> Message-ID: On Fri, 15 Mar 2024 18:10:52 GMT, Anthony Vanelverdinghe wrote: > If so, I believe the return type ought to be `Optional`. That way `text` could return `Optional.of("")` whereas `text.` would return `Optional.empty()`. I?think those should be?the?other way?around, e.g.: - `"text"` ? `Optional.empty()` - `"text."` ? `Optional.of("")` ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-2001955281 From duke at openjdk.org Sat Mar 16 22:23:40 2024 From: duke at openjdk.org (Anthony Vanelverdinghe) Date: Sat, 16 Mar 2024 22:23:40 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8] In-Reply-To: References: <8E5VOdhiIyY6BzHE44QEi6i_2eK8oMKbgTauVBRmqrY=.3ed2a7e3-b9fb-42c1-965a-13280c98ec59@github.com> Message-ID: On Sat, 16 Mar 2024 11:23:50 GMT, ExE Boss wrote: > I think those should be the other way around, e.g.: Not in the case I'm talking about. In that case, "if there's no debate possible, we return the file extension. Otherwise, we return the empty string", all I'm saying is that I believe it should be: "if there's no debate possible, we return `Optional.of(the file extension)`. Otherwise, we return `Optional.empty()`". So for `"text"` there's no debate possible and you get `Optional.of("")`. For `"text."` there is debate possible and you get `Optional.empty()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-2001964749 From duke at openjdk.org Sun Mar 17 18:31:50 2024 From: duke at openjdk.org (Nizar Benalla) Date: Sun, 17 Mar 2024 18:31:50 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v2] In-Reply-To: References: Message-ID: > # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 > > I changed the @\since tags to better accurately show when the methods and constructors were introduced. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: fixed @ since tag for Channels.java class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/8a829541..e80f99e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=00-01 Stats: 6 lines in 1 file changed: 2 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From duke at openjdk.org Sun Mar 17 23:40:50 2024 From: duke at openjdk.org (Nizar Benalla) Date: Sun, 17 Mar 2024 23:40:50 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v3] In-Reply-To: References: Message-ID: > # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 > > I changed the @\since tags to better accurately show when the methods and constructors were introduced. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - fixed a mistake - fixed a mistake ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/e80f99e1..c51f6cb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From duke at openjdk.org Sun Mar 17 23:56:48 2024 From: duke at openjdk.org (Nizar Benalla) Date: Sun, 17 Mar 2024 23:56:48 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v4] In-Reply-To: References: Message-ID: > # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 > > I changed the @\since tags to better accurately show when the methods and constructors were introduced. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: final version for channels.java - might need to remove whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/c51f6cb9..8e5a711e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From duke at openjdk.org Mon Mar 18 00:02:31 2024 From: duke at openjdk.org (Nizar Benalla) Date: Mon, 18 Mar 2024 00:02:31 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v5] In-Reply-To: References: Message-ID: <9z0zSGIWOSNLzbXHUV0EVx88bAPaade33W-lnsPl3UI=.6ee04546-60ec-403b-bba8-2ed647b96876@github.com> > # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 > > I changed the @\since tags to better accurately show when the methods and constructors were introduced. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: remove whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/8e5a711e..4822dede Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From duke at openjdk.org Mon Mar 18 12:44:46 2024 From: duke at openjdk.org (Nizar Benalla) Date: Mon, 18 Mar 2024 12:44:46 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v6] In-Reply-To: References: Message-ID: > # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 > > I changed the @\since tags to better accurately show when the methods and constructors were introduced. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: added terminal new line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/4822dede..abc5a6ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From bhuang at openjdk.org Mon Mar 18 16:52:47 2024 From: bhuang at openjdk.org (Bill Huang) Date: Mon, 18 Mar 2024 16:52:47 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests Message-ID: This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. ------------- Commit messages: - Clean up temporary files after tests complete. Changes: https://git.openjdk.org/jdk/pull/18352/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327474 Stats: 42 lines in 11 files changed: 20 ins; 1 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/18352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352 PR: https://git.openjdk.org/jdk/pull/18352 From alanb at openjdk.org Mon Mar 18 22:52:21 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 18 Mar 2024 22:52:21 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang wrote: > This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. > > Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. > - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. > - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. test/jdk/java/nio/channels/unixdomain/Bind.java line 191: > 189: server.bind(null); > 190: UnixDomainSocketAddress usa = (UnixDomainSocketAddress)server.getLocalAddress(); > 191: usa.getPath().toFile().deleteOnExit(); The test already deletes the file, I think you just want a try-finally here, same comment on a few other tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1529408542 From jlu at openjdk.org Tue Mar 19 00:48:24 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 19 Mar 2024 00:48:24 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v6] In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > added terminal new line The `@since 10` tags look consistent with the JDK release those methods / constructors were introduced in. Can you update the latter years for the Oracle copyrights only in both these files, thanks. ------------- PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1944702560 From duke at openjdk.org Tue Mar 19 10:54:41 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 10:54:41 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v7] In-Reply-To: References: Message-ID: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com> > # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 > > I changed the @\since tags to better accurately show when the methods and constructors were introduced. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: update the latter years for the Oracle copyrights ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/abc5a6ab..8bcc364f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=05-06 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From duke at openjdk.org Tue Mar 19 10:54:41 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 10:54:41 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v6] In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > added terminal new line I have updated them ------------- PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2006812767 From duke at openjdk.org Tue Mar 19 11:23:36 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 11:23:36 GMT Subject: RFR: JDK-8326951 Missing @since Tags [v2] In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> Message-ID: > I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class. > > The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96). Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision: - Revert "fix rest of private/public since tags" This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1. - Revert "removed unnecessary @ since tags" This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660. - removed unnecessary @ since tags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18055/files - new: https://git.openjdk.org/jdk/pull/18055/files/2c04a9d8..ba97724d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=00-01 Stats: 10 lines in 10 files changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055 PR: https://git.openjdk.org/jdk/pull/18055 From jpai at openjdk.org Tue Mar 19 11:23:36 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Mar 2024 11:23:36 GMT Subject: RFR: JDK-8326951 Missing @since Tags [v2] In-Reply-To: References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> Message-ID: On Tue, 19 Mar 2024 11:21:14 GMT, Nizar Benalla wrote: >> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class. >> >> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96). > > Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision: > > - Revert "fix rest of private/public since tags" > > This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1. > - Revert "removed unnecessary @ since tags" > > This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660. > - removed unnecessary @ since tags src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68: > 66: * > 67: * @return {@inheritDoc java.security.AsymmetricKey} > 68: * @since 22 Hello Nizar, are the removal of `@since` in this PR intentional? I haven't checked all of them, but this specific removal appears incorrect, since this method was indeed introduced in Java 22 as part of https://bugs.openjdk.org/browse/JDK-8318096. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1526987579 From duke at openjdk.org Tue Mar 19 11:23:36 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 11:23:36 GMT Subject: RFR: JDK-8326951 Missing @since Tags [v2] In-Reply-To: References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> Message-ID: On Sat, 16 Mar 2024 00:20:51 GMT, Jaikiran Pai wrote: >> Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision: >> >> - Revert "fix rest of private/public since tags" >> >> This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1. >> - Revert "removed unnecessary @ since tags" >> >> This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660. >> - removed unnecessary @ since tags > > src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68: > >> 66: * >> 67: * @return {@inheritDoc java.security.AsymmetricKey} >> 68: * @since 22 > > Hello Nizar, are the removal of `@since` in this PR intentional? I haven't checked all of them, but this specific removal appears incorrect, since this method was indeed introduced in Java 22 as part of https://bugs.openjdk.org/browse/JDK-8318096. Hello Jaikiran, in jdk21 DHPPublicKey did have a [getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244) method, so it is not new in jdk 22. It also existed [before that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252) If you haven't looked at the other cases, I was about to group the changes related to the Key interfaces in a separate PR if that's fine. let me know what you think ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1527393223 From jlahoda at openjdk.org Tue Mar 19 11:23:36 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 19 Mar 2024 11:23:36 GMT Subject: RFR: JDK-8326951 Missing @since Tags [v2] In-Reply-To: References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> Message-ID: On Sun, 17 Mar 2024 01:20:17 GMT, Nizar Benalla wrote: >> src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68: >> >>> 66: * >>> 67: * @return {@inheritDoc java.security.AsymmetricKey} >>> 68: * @since 22 >> >> Hello Nizar, are the removal of `@since` in this PR intentional? I haven't checked all of them, but this specific removal appears incorrect, since this method was indeed introduced in Java 22 as part of https://bugs.openjdk.org/browse/JDK-8318096. > > Hello Jaikiran, > in jdk21 DHPPublicKey did have a [getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244) method, so it is not new in jdk 22. It also existed [before that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252) > > If you haven't looked at the other cases, I was about to group the changes related to the Key interfaces in a separate PR if that's fine. let me know what you think Hello, While the override of `getParams` in `DHPublicKey` was added, the `getParams` method has been inherited to `DHPublicKey` for a long time from `DHKey`. E.g., I can take this: import javax.crypto.interfaces.DHPublicKey; public class DhkeyTest { public static void main(DHPublicKey key) { System.err.println(key.getParams()); } } and compile using JDK 8 without any compile-time errors. So, it would make more sense to me to not add the `@since` for it. I believe Nizar will separate the changes to the Key interfaces into a separate PR, so we can discuss in more detail there. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1528625403 From jpai at openjdk.org Tue Mar 19 11:23:36 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Mar 2024 11:23:36 GMT Subject: RFR: JDK-8326951 Missing @since Tags [v2] In-Reply-To: References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> Message-ID: On Mon, 18 Mar 2024 14:02:20 GMT, Jan Lahoda wrote: >> Hello Jaikiran, >> in jdk21 DHPPublicKey did have a [getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244) method, so it is not new in jdk 22. It also existed [before that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252) >> >> If you haven't looked at the other cases, I was about to group the changes related to the Key interfaces in a separate PR if that's fine. let me know what you think > > Hello, > > While the override of `getParams` in `DHPublicKey` was added, the `getParams` method has been inherited to `DHPublicKey` for a long time from `DHKey`. E.g., I can take this: > > import javax.crypto.interfaces.DHPublicKey; > > public class DhkeyTest { > > public static void main(DHPublicKey key) { > System.err.println(key.getParams()); > } > > } > > > and compile using JDK 8 without any compile-time errors. So, it would make more sense to me to not add the `@since` for it. > > I believe Nizar will separate the changes to the Key interfaces into a separate PR, so we can discuss in more detail there. > > Thanks! Hello Jan, interesting. I hadn't noticed that `javax.crypto.interfaces.DHPublicKey` already was exposing `getParams()` in earlier versions because `javax.crypto.interfaces.DHPublicKey` extends from `javax.crypto.interfaces.DHKey` which has the `getParams()` method. > I believe Nizar will separate the changes to the Key interfaces into a separate PR, so we can discuss in more detail there. That sounds fine to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1528641492 From duke at openjdk.org Tue Mar 19 15:54:34 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 15:54:34 GMT Subject: RFR: JDK-8326951 Missing @since Tags [v3] In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> Message-ID: <7uRhl1-KqL4yOiC8H_8iDbliZlj9nB3I5oC6Kf9FeV8=.8bbf14de-6d8a-4ae9-b6bb-a964944396cc@github.com> > I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class. > > The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96). Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: added since tag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18055/files - new: https://git.openjdk.org/jdk/pull/18055/files/ba97724d..3cec63e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055 PR: https://git.openjdk.org/jdk/pull/18055 From jlu at openjdk.org Tue Mar 19 16:16:24 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 19 Mar 2024 16:16:24 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v7] In-Reply-To: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com> References: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com> Message-ID: <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com> On Tue, 19 Mar 2024 10:54:41 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > update the latter years for the Oracle copyrights src/java.base/share/classes/java/nio/channels/Channels.java line 2: > 1: /* > 2: * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved. Thanks for updating, but needs a little adjustment. Rather than adding a third year, the format should be: "original year, current year, Oracle ..." So in this case -> `2000, 2024,` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530694415 From duke at openjdk.org Tue Mar 19 17:02:36 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 17:02:36 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v8] In-Reply-To: References: Message-ID: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> > # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 > > I changed the @\since tags to better accurately show when the methods and constructors were introduced. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - update the copyright year to 2024 - Revert "update the latter years for the Oracle copyrights" This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/8bcc364f..56968dcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From duke at openjdk.org Tue Mar 19 17:08:23 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 17:08:23 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v7] In-Reply-To: <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com> References: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com> <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com> Message-ID: On Tue, 19 Mar 2024 16:13:49 GMT, Justin Lu wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> update the latter years for the Oracle copyrights > > src/java.base/share/classes/java/nio/channels/Channels.java line 2: > >> 1: /* >> 2: * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved. > > Thanks for updating, but needs a little adjustment. > > Rather than adding a third year, the format should be: "original year, current year, Oracle ..." > So in this case -> `2000, 2024,` Thanks for the explanation, I have fixed it. I have a couple other similar PRs, is the policy to update the copyright year every time a file is changed? whether it's an addition or removal of code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530770401 From jlu at openjdk.org Tue Mar 19 17:23:21 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 19 Mar 2024 17:23:21 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v7] In-Reply-To: References: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com> <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com> Message-ID: On Tue, 19 Mar 2024 17:05:50 GMT, Nizar Benalla wrote: >> src/java.base/share/classes/java/nio/channels/Channels.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved. >> >> Thanks for updating, but needs a little adjustment. >> >> Rather than adding a third year, the format should be: "original year, current year, Oracle ..." >> So in this case -> `2000, 2024,` > > Thanks for the explanation, I have fixed it. > I have a couple other similar PRs, is the policy to update the copyright year every time a file is changed? whether it's an addition or removal of code? Yes, you should update the copyright year to the current year if you make a change to the file, regardless if the change itself is "significant" or not. Note that there are two formats: `Year1, Year2, Oracle` and `Year, Oracle`. The latter would be used if say you added a new file in 2024. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530792055 From jlu at openjdk.org Tue Mar 19 17:32:21 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 19 Mar 2024 17:32:21 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v8] In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> References: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> Message-ID: On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - update the copyright year to 2024 > - Revert "update the latter years for the Oracle copyrights" > > This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64. Change looks good to me, but you will need someone with reviewer status to sponsor your changes before you can integrate them. BTW, I also added a `noreg-doc` label to your JBS issue, which just means that no tests are needed for this change as it is a documentation only change. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1946933024 From bhuang at openjdk.org Tue Mar 19 17:58:46 2024 From: bhuang at openjdk.org (Bill Huang) Date: Tue, 19 Mar 2024 17:58:46 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2] In-Reply-To: References: Message-ID: > This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. > > Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. > - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. > - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18352/files - new: https://git.openjdk.org/jdk/pull/18352/files/8472c31f..620f9259 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00-01 Stats: 136 lines in 5 files changed: 36 ins; 13 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/18352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352 PR: https://git.openjdk.org/jdk/pull/18352 From duke at openjdk.org Tue Mar 19 18:02:21 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 18:02:21 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v8] In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> References: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> Message-ID: On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - update the copyright year to 2024 > - Revert "update the latter years for the Oracle copyrights" > > This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64. Thank you justin ------------- PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2007813492 From duke at openjdk.org Wed Mar 20 02:17:36 2024 From: duke at openjdk.org (Nizar Benalla) Date: Wed, 20 Mar 2024 02:17:36 GMT Subject: RFR: JDK-8326951 Missing @since Tags [v4] In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com> Message-ID: > I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class. > > The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96). Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision: - update the copyright year to 2024 - Revert "update the copyright year to 2024" This reverts commit 9ddd230dcf88bedade76a8e2804db6e120a200f8. - update the copyright year to 2024 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18055/files - new: https://git.openjdk.org/jdk/pull/18055/files/3cec63e9..7d6e969e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=02-03 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055 PR: https://git.openjdk.org/jdk/pull/18055 From egahlin at openjdk.org Wed Mar 20 10:27:22 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 20 Mar 2024 10:27:22 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2] In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang wrote: >> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. >> >> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. >> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. >> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments Speaking for JFR, we should probably just create a normal file, possibly with a filename to indicate subtest and iteration. That said, test changes for JFR looks fine, and fixing the filename is outside the scope of this bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2009218768 From naoto at openjdk.org Wed Mar 20 17:46:24 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 20 Mar 2024 17:46:24 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v8] In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> References: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> Message-ID: On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - update the copyright year to 2024 > - Revert "update the latter years for the Oracle copyrights" > > This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64. LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1949627443 From duke at openjdk.org Wed Mar 20 18:04:50 2024 From: duke at openjdk.org (Nizar Benalla) Date: Wed, 20 Mar 2024 18:04:50 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v9] In-Reply-To: References: Message-ID: <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com> > # Issue > - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10 > > I changed the `@since` tags to better accurately show when the methods and constructors were introduced. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - Update full name - Update full name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/56968dcd..99f54fe2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=07-08 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032 From jpai at openjdk.org Thu Mar 21 14:44:20 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Mar 2024 14:44:20 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2] In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang wrote: >> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. >> >> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. >> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. >> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57: > 55: > 56: File flagsFile = File.createTempFile("CheckOriginFlags", null); > 57: flagsFile.deleteOnExit(); Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary). Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do: File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile(); and don't need any explicit deletions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534054951 From jpai at openjdk.org Thu Mar 21 15:05:26 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Mar 2024 15:05:26 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2] In-Reply-To: References: Message-ID: <-LZotlcsvx3EbHNNn0DO-u7HsWB302dYqZ33vFTf0UA=.9728ca78-a90f-4705-8b81-de5c61d342ca@github.com> On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang wrote: >> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. >> >> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. >> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. >> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments test/jdk/java/nio/channels/unixdomain/Bind.java line 201: > 199: System.out.println("Null server address: " + server.getLocalAddress()); > 200: } finally { > 201: Files.deleteIfExists(usa.getPath()); `usa` can be `null` here, if it never got assigned due to some exception in the prior lines, which can lead to a `NullPointerException` here. test/jdk/java/nio/channels/unixdomain/Bind.java line 341: > 339: assertAddress(client.getRemoteAddress(), usa, "server"); > 340: } finally { > 341: Files.deleteIfExists(usa.getPath()); Same applies here about potential NullPointerException and some other places in other files as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534092806 PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534095046 From jpai at openjdk.org Thu Mar 21 15:09:21 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Mar 2024 15:09:21 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2] In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang wrote: >> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. >> >> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. >> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. >> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95: > 93: > 94: // ensure that the archive is still readable, and the date is 1979-11-30 > 95: Path path = Utils.createTempFile("out", ".zip"); So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534105420 From jlu at openjdk.org Thu Mar 21 16:53:23 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 21 Mar 2024 16:53:23 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v8] In-Reply-To: References: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> Message-ID: On Tue, 19 Mar 2024 17:59:48 GMT, Nizar Benalla wrote: >> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: >> >> - update the copyright year to 2024 >> - Revert "update the latter years for the Oracle copyrights" >> >> This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64. > > Thank you justin Hi @nizarbenalla , you can comment `/integrate` whenever you're ready, and we can sponsor the change to have it integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2012982347 From bhuang at openjdk.org Thu Mar 21 16:54:21 2024 From: bhuang at openjdk.org (Bill Huang) Date: Thu, 21 Mar 2024 16:54:21 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 14:41:36 GMT, Jaikiran Pai wrote: >> Bill Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented review comments > > test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57: > >> 55: >> 56: File flagsFile = File.createTempFile("CheckOriginFlags", null); >> 57: flagsFile.deleteOnExit(); > > Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary). > Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do: > > > File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile(); > > and don't need any explicit deletions? Hi Jaikiran, I think both solutions work for this bug. I personally prefer to place the files in the scratch directory for the ease of debugging. In addition, for this specific test, I am considering using File.createTempFile("CheckOriginaFlags", null, Path.of(".").toFile) instead of Files.createTempFile for consistency purposes, as Files.createTempFile may have more restrictive access permissions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534283105 From bhuang at openjdk.org Thu Mar 21 16:59:20 2024 From: bhuang at openjdk.org (Bill Huang) Date: Thu, 21 Mar 2024 16:59:20 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2] In-Reply-To: References: Message-ID: <5fp1NwbiBibdMUnZA8mIj76MLVvTxdA2m_z9IM8dUEc=.28d46052-8e8d-4ede-96ac-5da5d7a568a9@github.com> On Thu, 21 Mar 2024 15:06:58 GMT, Jaikiran Pai wrote: >> Bill Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented review comments > > test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95: > >> 93: >> 94: // ensure that the archive is still readable, and the date is 1979-11-30 >> 95: Path path = Utils.createTempFile("out", ".zip"); > > So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`? Yes, you are right. We don't need explicit deletion for these files by using this util method, Utils.createTempFile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534290137 From bhuang at openjdk.org Thu Mar 21 17:13:46 2024 From: bhuang at openjdk.org (Bill Huang) Date: Thu, 21 Mar 2024 17:13:46 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3] In-Reply-To: References: Message-ID: > This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. > > Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. > - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. > - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Fixed potential NPE issues. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18352/files - new: https://git.openjdk.org/jdk/pull/18352/files/620f9259..2517f756 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=01-02 Stats: 11 lines in 4 files changed: 5 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/18352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352 PR: https://git.openjdk.org/jdk/pull/18352 From mullan at openjdk.org Thu Mar 21 17:46:20 2024 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 21 Mar 2024 17:46:20 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang wrote: >> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. >> >> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. >> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. >> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Fixed potential NPE issues. The bug should have a `noreg-self` label. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2013158192 From duke at openjdk.org Fri Mar 22 10:28:24 2024 From: duke at openjdk.org (Nizar Benalla) Date: Fri, 22 Mar 2024 10:28:24 GMT Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v9] In-Reply-To: <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com> References: <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com> Message-ID: On Wed, 20 Mar 2024 18:04:50 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10 >> >> I changed the `@since` tags to better accurately show when the methods and constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - Update full name > - Update full name I spent some time running some tests to learn the process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2014786660 From duke at openjdk.org Fri Mar 22 15:52:28 2024 From: duke at openjdk.org (Nizar Benalla) Date: Fri, 22 Mar 2024 15:52:28 GMT Subject: RFR: JDK-8326853 Missing @ since tags for Charset related methods added in Java 10 [v8] In-Reply-To: References: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com> Message-ID: On Thu, 21 Mar 2024 16:50:31 GMT, Justin Lu wrote: >> Thank you justin > > Hi @nizarbenalla , you can comment `/integrate` whenever you're ready, and we can sponsor the change to have it integrated. @justin-curtis-lu I realized there is a small issue with the commit message 8326853: Missing @since tags for Charset related methods added in Java 10 Reviewed-by: jlu, naoto there is a github user with the username `@since` and he will be tagged in the commit message, so there should be a space here. I added a space in the PR title ------------- PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2015380584 From duke at openjdk.org Fri Mar 22 16:14:26 2024 From: duke at openjdk.org (Nizar Benalla) Date: Fri, 22 Mar 2024 16:14:26 GMT Subject: Integrated: JDK-8326853 Missing `@since` tags for Charset related methods added in Java 10 In-Reply-To: References: Message-ID: <4cUvcPClyJ-k2flHg2HTAheLLeCUKQsee04x-gQ9B5M=.6eefac93-ca3d-435a-990b-27de51410e3c@github.com> On Tue, 27 Feb 2024 16:28:26 GMT, Nizar Benalla wrote: > # Issue > - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10 > > I changed the `@since` tags to better accurately show when the methods and constructors were introduced. This pull request has now been integrated. Changeset: 4d932d61 Author: Nizar Benalla Committer: Justin Lu URL: https://git.openjdk.org/jdk/commit/4d932d615c78f45516a4f136398e7610546065a6 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod 8326853: Missing `@since` tags for Charset related methods added in Java 10 Reviewed-by: jlu, naoto ------------- PR: https://git.openjdk.org/jdk/pull/18032 From aturbanov at openjdk.org Tue Mar 26 07:30:23 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 26 Mar 2024 07:30:23 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang wrote: >> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. >> >> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. >> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. >> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Fixed potential NPE issues. test/jdk/java/nio/channels/unixdomain/Bind.java line 162: > 160: // address with space should work > 161: checkNormal(() -> { > 162: UnixDomainSocketAddress usa = UnixDomainSocketAddress.of("with space"); Suggestion: UnixDomainSocketAddress usa = UnixDomainSocketAddress.of("with space"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1538701870 From michaelm at openjdk.org Tue Mar 26 15:56:23 2024 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 26 Mar 2024 15:56:23 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang wrote: >> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. >> >> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. >> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. >> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Fixed potential NPE issues. unixdomain NIO test changes look fine to me ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1960889711 From bhuang at openjdk.org Tue Mar 26 18:18:39 2024 From: bhuang at openjdk.org (Bill Huang) Date: Tue, 26 Mar 2024 18:18:39 GMT Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4] In-Reply-To: References: Message-ID: > This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. > > Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. > - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. > - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/nio/channels/unixdomain/Bind.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18352/files - new: https://git.openjdk.org/jdk/pull/18352/files/2517f756..0f4130a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352 PR: https://git.openjdk.org/jdk/pull/18352 From tprinzing at openjdk.org Fri Mar 29 00:56:46 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Fri, 29 Mar 2024 00:56:46 GMT Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event Message-ID: Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods. Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event. Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor. Uses the existing tests. ------------- Commit messages: - javadoc fixup - remove mirrors from JDKEvents - 8329138: Convert JFR FileForceEvent to static mirror event Changes: https://git.openjdk.org/jdk/pull/18542/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329138 Stats: 159 lines in 7 files changed: 123 ins; 30 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/18542.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542 PR: https://git.openjdk.org/jdk/pull/18542 From alanb at openjdk.org Fri Mar 29 01:52:35 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 29 Mar 2024 01:52:35 GMT Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event In-Reply-To: References: Message-ID: On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing wrote: > Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods. > > Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event. > > Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor. > > Uses the existing tests. The other two places that should probably emit this event are FileDescriptor.sync and AsynchonrousFileChannel.force. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2026460366 From tprinzing at openjdk.org Fri Mar 29 20:51:31 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Fri, 29 Mar 2024 20:51:31 GMT Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event In-Reply-To: References: Message-ID: On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing wrote: > Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods. > > Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event. > > Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor. > > Uses the existing tests. Okay, I'll update those two places to emit the event. It looks like adding a file descriptor property to the event is needed, and there would be no file path in those cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2027722419 From alanb at openjdk.org Sat Mar 30 10:08:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 30 Mar 2024 10:08:30 GMT Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event In-Reply-To: References: Message-ID: <5WxpEWPgGFA1cNFyaD0ww5qSGnC1a1axgcgzBcH22CA=.6b54905a-92fd-4d2c-84cf-ffabd88be2c0@github.com> On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing wrote: > Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods. > > Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event. > > Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor. > > Uses the existing tests. > It looks like adding a file descriptor property to the event is needed, and there would be no file path in those cases. The AsynchonrousFileChannel implementations can keep a reference to the file path, that should be easy. FileDescriptor.sync does need more thought, maybe it's not worth doing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2028000449