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: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@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".

-------------

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: <yY6OPMTxHE_9lIMfUcaOzHZIdnD2oQWNlgoYilh7jxs=.6907c1dc-5c83-4f60-a700-d6d2d4a2449d@github.com>
References: <ltlQjcw0EJp6-fMYoICJHSd3yqLIkQosn2Aaa8qVmqQ=.98de2c96-eb45-4b74-8548-4e11cd968c53@github.com>
 <yY6OPMTxHE_9lIMfUcaOzHZIdnD2oQWNlgoYilh7jxs=.6907c1dc-5c83-4f60-a700-d6d2d4a2449d@github.com>
Message-ID: <PVg4V5QrcfXmY24OUwP_wfcIsEEkkQkXdSnAd6atxF4=.eb69d315-e524-4eaf-b52d-a95565eec677@github.com>

On Thu, 29 Feb 2024 15:03:18 GMT, Pavel Rappo <prappo at openjdk.org> 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: <ltlQjcw0EJp6-fMYoICJHSd3yqLIkQosn2Aaa8qVmqQ=.98de2c96-eb45-4b74-8548-4e11cd968c53@github.com>
References: <ltlQjcw0EJp6-fMYoICJHSd3yqLIkQosn2Aaa8qVmqQ=.98de2c96-eb45-4b74-8548-4e11cd968c53@github.com>
Message-ID: <B27-lsbq9U2SF7anNl8GSvVvWEXOc4eWTWdeNtZd-DM=.720cea95-674d-4c88-beb1-83180f7ef218@github.com>

> 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: <B27-lsbq9U2SF7anNl8GSvVvWEXOc4eWTWdeNtZd-DM=.720cea95-674d-4c88-beb1-83180f7ef218@github.com>
References: <ltlQjcw0EJp6-fMYoICJHSd3yqLIkQosn2Aaa8qVmqQ=.98de2c96-eb45-4b74-8548-4e11cd968c53@github.com>
 <B27-lsbq9U2SF7anNl8GSvVvWEXOc4eWTWdeNtZd-DM=.720cea95-674d-4c88-beb1-83180f7ef218@github.com>
Message-ID: <jjNjOhT4FiuUBOp5xjyd827XJy4Svb3W0gRzRWBY2Mw=.4b406358-11a6-42c2-adb1-4ac63245d5e0@github.com>

On Fri, 1 Mar 2024 09:43:26 GMT, Pavel Rappo <prappo at openjdk.org> 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: <ltlQjcw0EJp6-fMYoICJHSd3yqLIkQosn2Aaa8qVmqQ=.98de2c96-eb45-4b74-8548-4e11cd968c53@github.com>
References: <ltlQjcw0EJp6-fMYoICJHSd3yqLIkQosn2Aaa8qVmqQ=.98de2c96-eb45-4b74-8548-4e11cd968c53@github.com>
Message-ID: <GWcJNM21gradfY6-Awl8-XxAZmCqTx2QEZMdMmrOByg=.28760b1b-b185-4702-8ea6-407f9116456e@github.com>

On Thu, 29 Feb 2024 12:56:35 GMT, Pavel Rappo <prappo at openjdk.org> 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 <prappo at openjdk.org>
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: <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>

> 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: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>

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: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <CEkugr_uiWOQVlTh-FSsLj6fdUX5OYfruGxJYRgSGJA=.9dcff5f4-f18d-454f-8bfd-ee6c2785780d@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
Message-ID: <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>

On Wed, 6 Mar 2024 14:13:26 GMT, Alan Bateman <alanb at openjdk.org> 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: <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
 <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>
Message-ID: <BVmjS3qMP7guv_LjBz9fvwLS6JAmt2GX_00IGe-_7-w=.3b422e7b-1d0a-4ff7-9e4f-eae6879e44b2@github.com>

On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>

> 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: <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
Message-ID: <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>

On Wed, 6 Mar 2024 15:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
 <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>
Message-ID: <k8YDbMN1Y1cM_HIgm6gqsdDDDXXQEgSDDWd98ZfhjEk=.869ed36b-dcd5-477c-9e96-db6aa1817ed5@github.com>

On Wed, 6 Mar 2024 15:49:05 GMT, Alan Bateman <alanb at openjdk.org> 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: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>

> 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: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> 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 <sys/un.h>
> 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <rnkqi5v3uurTdsZFX6XTFKBWW2t50Oq9tVGQPmw_W0M=.f56f8f0f-b9ea-41ad-932c-9660b2e6f996@github.com>

> 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: <HL71oZtMPh0ry8U3SSV3L1tRfB9QeC-A7463N9HH15w=.6b7b273d-6403-4a88-a535-466fe89bf1ff@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <HL71oZtMPh0ry8U3SSV3L1tRfB9QeC-A7463N9HH15w=.6b7b273d-6403-4a88-a535-466fe89bf1ff@github.com>
Message-ID: <gh2fAu2iYtRnTlBxi9OOvVcb_OTYkfnSmTR9CK1vc9g=.256060c9-44df-4ca3-aaed-e27807498d53@github.com>

On Mon, 20 Nov 2023 23:30:45 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <fhQS5gSfJY97afRfza4rCgMmYn5PgFCn5R-0kzh9cEw=.940f0924-03be-49f0-878f-d2724c164e59@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>

> 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: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
Message-ID: <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>

On Thu, 7 Mar 2024 03:00:11 GMT, Guoxiong Li <gli at openjdk.org> 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: <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
 <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>
Message-ID: <3Oc7Dtnp_h7ivbUNx3RvJI1ltC3elMhB6V8Jijp2k_0=.d3081a47-6f3b-4051-8baa-a7254be58293@github.com>

On Thu, 7 Mar 2024 07:20:15 GMT, David Holmes <dholmes at openjdk.org> 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: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
Message-ID: <5LGbdPzlc3oIQ3TGaN5iglmGa5MCt5YnJzLvE7KUu6s=.b2a22f10-8331-4f15-8a2d-affbef828876@github.com>

On Wed, 6 Mar 2024 17:16:03 GMT, Christoph Langer <clanger at openjdk.org> 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: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>

> 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: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
Message-ID: <9srUL7ZFMpINp-3Ub6V1mN5RYsiwkPxsQZnET_9sBVk=.3a051bf1-cc2f-47cb-b2f3-d220f32a91ce@github.com>

On Wed, 6 Mar 2024 17:14:25 GMT, Christoph Langer <clanger at openjdk.org> 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: <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>
Message-ID: <YhcFIomZE7c7bxw3SqUp2wOkKUZOBq1CnJriSGgjcFg=.dfa9f18c-51f3-47e1-b88c-caabbe2d7a3f@github.com>

On Thu, 7 Mar 2024 08:08:45 GMT, Alan Bateman <alanb at openjdk.org> 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: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <okOd6cZT8f3vs6OvAfShpYuA_m1jny4FP-pNRjFJBDY=.d45787d7-5344-4d08-bb9a-19f1645526fd@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <zlGKCDnKizB8QBmTV4zoyB_Tu2sc6eAlaz8t7Wg09lc=.c3015b98-4071-48fc-85d9-d816b0945420@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
Message-ID: <CWb_XlWY73a6In51FGgyKm3xNIY4OCgHFytcpNra_Uk=.56aabd72-d48c-4fad-b702-3cd1434a9214@github.com>

On Wed, 6 Mar 2024 23:41:05 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
Message-ID: <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>

On Wed, 6 Mar 2024 23:41:05 GMT, Brian Burkhalter <bpb at openjdk.org> 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:      * <p> 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: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <aCwdTOl0-rkQj9VyYVBDEaZ5D3PJut6U2vy07APIWoU=.bed1e600-78d7-4d26-8231-3a39d079aa93@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>
Message-ID: <1ViK8IUchGK_5FmUqVUDrC-ujqv7WZEAX2aoo-l70k0=.72d5fbc5-7325-4b74-a115-91db443e214c@github.com>

On Thu, 7 Mar 2024 16:45:58 GMT, Roger Riggs <rriggs at openjdk.org> 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: <HL71oZtMPh0ry8U3SSV3L1tRfB9QeC-A7463N9HH15w=.6b7b273d-6403-4a88-a535-466fe89bf1ff@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <HL71oZtMPh0ry8U3SSV3L1tRfB9QeC-A7463N9HH15w=.6b7b273d-6403-4a88-a535-466fe89bf1ff@github.com>
Message-ID: <lXBf_SI7QOopGj0HxP1lWW2aFkpwdWjh9KP-VgVAqy0=.0310172c-97a7-4246-8acf-bb6296b07c8e@github.com>

On Mon, 20 Nov 2023 23:30:45 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>
Message-ID: <rB2NDJIeU15RzkWeT8fJgynQdE0ZE8UucYtv3LxvpgE=.9a146836-d581-4e36-bd02-bad404b219e3@github.com>

On Thu, 7 Mar 2024 16:59:54 GMT, Roger Riggs <rriggs at openjdk.org> 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: <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
Message-ID: <plLjDG2-mzy7Si1MS8xM-d5vT8J4bl2VPGfS2S_1nEg=.8dacb21d-3450-4ddc-b639-5604e06f7503@github.com>

On Wed, 6 Mar 2024 23:41:05 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <rB2NDJIeU15RzkWeT8fJgynQdE0ZE8UucYtv3LxvpgE=.9a146836-d581-4e36-bd02-bad404b219e3@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>
 <rB2NDJIeU15RzkWeT8fJgynQdE0ZE8UucYtv3LxvpgE=.9a146836-d581-4e36-bd02-bad404b219e3@github.com>
Message-ID: <3GQE-KMR_qKGw_TbgvkdkK8aeUa5rq7v5nL6LA6KCpc=.75d35f3b-9d2b-4ba8-a8c2-e74f89dd6509@github.com>

On Thu, 7 Mar 2024 20:33:36 GMT, Louis Bergelson <duke at openjdk.org> 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: <JwZxCNT0ulu-RLMOQ5P65OG5cR5QjqzOKtJ-rMswuTY=.f1ec3dff-081b-4485-b8e7-f580a4709ff6@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <JwZxCNT0ulu-RLMOQ5P65OG5cR5QjqzOKtJ-rMswuTY=.f1ec3dff-081b-4485-b8e7-f580a4709ff6@github.com>
Message-ID: <G6gWV5IS1LXkZFgE3Vg9248Q3qTlxof-kZgQaH_4Cg4=.c9a35e27-8bb9-432c-9783-4eaadb9213a8@github.com>

On Sat, 3 Feb 2024 17:28:29 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> 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: <plLjDG2-mzy7Si1MS8xM-d5vT8J4bl2VPGfS2S_1nEg=.8dacb21d-3450-4ddc-b639-5604e06f7503@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <plLjDG2-mzy7Si1MS8xM-d5vT8J4bl2VPGfS2S_1nEg=.8dacb21d-3450-4ddc-b639-5604e06f7503@github.com>
Message-ID: <AFxhGYtKvP3WoO5RCjf6JzQ9eIIfB4GnxNTDXi2Cs38=.5e64ce28-2faf-4ce6-a724-922a56741746@github.com>

On Thu, 7 Mar 2024 20:31:55 GMT, Louis Bergelson <duke at openjdk.org> 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <jOzNTCT6GB-5FSdDNFGoAAyEMkfhnRa4vxLgyrhrjjc=.00d25070-cbb2-4df7-ba89-5151d9e438f2@github.com>

> 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>

> 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: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <bAbzLLRP89_PJUmeQMuGg37Djvavu4QQ1k94VFDHUUU=.a08c190a-9c3c-429f-af8f-ddca2e471161@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> 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 <mbaesken at openjdk.org>
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: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
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: <AFxhGYtKvP3WoO5RCjf6JzQ9eIIfB4GnxNTDXi2Cs38=.5e64ce28-2faf-4ce6-a724-922a56741746@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <plLjDG2-mzy7Si1MS8xM-d5vT8J4bl2VPGfS2S_1nEg=.8dacb21d-3450-4ddc-b639-5604e06f7503@github.com>
 <AFxhGYtKvP3WoO5RCjf6JzQ9eIIfB4GnxNTDXi2Cs38=.5e64ce28-2faf-4ce6-a724-922a56741746@github.com>
Message-ID: <2eYe5macx7jja9Lq_MG063WZCFA-OaxtN-mEZYvsu78=.53317446-96ac-4ee4-a70d-e7536a74cd25@github.com>

On Thu, 7 Mar 2024 21:23:11 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>
Message-ID: <K9ZF3yU-XSESUSZavX_XERw-_bpsWkRUKOGVuLpZoFQ=.41531c4c-9646-4d4c-893b-fad8fddd24a1@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240308/9fb8319c/attachment.htm>

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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <plLjDG2-mzy7Si1MS8xM-d5vT8J4bl2VPGfS2S_1nEg=.8dacb21d-3450-4ddc-b639-5604e06f7503@github.com>
 <AFxhGYtKvP3WoO5RCjf6JzQ9eIIfB4GnxNTDXi2Cs38=.5e64ce28-2faf-4ce6-a724-922a56741746@github.com>
 <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 <rriggs at openjdk.org> 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>
 <rB2NDJIeU15RzkWeT8fJgynQdE0ZE8UucYtv3LxvpgE=.9a146836-d581-4e36-bd02-bad404b219e3@github.com>
 <3GQE-KMR_qKGw_TbgvkdkK8aeUa5rq7v5nL6LA6KCpc=.75d35f3b-9d2b-4ba8-a8c2-e74f89dd6509@github.com>
Message-ID: <DFpN6sA33C2TjuYU8cZuINNu4gR29mryOrDPo0iFSL4=.12f8ee9e-382e-4510-b161-e70f6a76ad54@github.com>

On Thu, 7 Mar 2024 21:14:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
References: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
Message-ID: <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com>

On Thu, 29 Feb 2024 23:54:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <K9ZF3yU-XSESUSZavX_XERw-_bpsWkRUKOGVuLpZoFQ=.41531c4c-9646-4d4c-893b-fad8fddd24a1@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>
 <K9ZF3yU-XSESUSZavX_XERw-_bpsWkRUKOGVuLpZoFQ=.41531c4c-9646-4d4c-893b-fad8fddd24a1@github.com>
Message-ID: <1Nb1p69nmPMAKf_qfEqAvW5dKMJqwbDTgUWk4eHeUhY=.5c5fa864-a941-49bc-b6cd-5c79d6aa88e4@github.com>

On Fri, 8 Mar 2024 17:30:21 GMT, Anthony Vanelverdinghe <duke at openjdk.org> 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <plLjDG2-mzy7Si1MS8xM-d5vT8J4bl2VPGfS2S_1nEg=.8dacb21d-3450-4ddc-b639-5604e06f7503@github.com>
 <AFxhGYtKvP3WoO5RCjf6JzQ9eIIfB4GnxNTDXi2Cs38=.5e64ce28-2faf-4ce6-a724-922a56741746@github.com>
 <2eYe5macx7jja9Lq_MG063WZCFA-OaxtN-mEZYvsu78=.53317446-96ac-4ee4-a70d-e7536a74cd25@github.com>
 <3cNqF1QskP0JkVXi6cDAcUQ2dBdirXKJLVLXnu0Lfao=.4fc8c4ab-14fc-4689-8df5-2db2fe18d92f@github.com>
Message-ID: <K4xyh16AFHEJCucn8vtE1qQLibC2fx304xtP3oRF3b8=.01592d52-5ec4-485b-9878-55f52c15268c@github.com>

On Fri, 8 Mar 2024 19:36:15 GMT, Louis Bergelson <duke at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@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.

-------------

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: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
 <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com>
Message-ID: <MR35wMmbTnppMe9F6CzuUW6JFw34XfI8HYWt5L5uNBc=.70a21e7b-a9c4-4ac1-a622-eb87daa2f311@github.com>

On Mon, 11 Mar 2024 09:51:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <MR35wMmbTnppMe9F6CzuUW6JFw34XfI8HYWt5L5uNBc=.70a21e7b-a9c4-4ac1-a622-eb87daa2f311@github.com>
References: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
 <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com>
 <MR35wMmbTnppMe9F6CzuUW6JFw34XfI8HYWt5L5uNBc=.70a21e7b-a9c4-4ac1-a622-eb87daa2f311@github.com>
Message-ID: <Xapo3EQgEEPO6-c6mDAZ_rWpXrXwlD_cEUoGJDzooPU=.bacecfd1-79b1-4cf1-aba2-b7b2530c06d4@github.com>

On Mon, 11 Mar 2024 17:56:24 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
Message-ID: <RED03_23-9fDt5pKBfgAtc_o2TJDxZ16IGaNIWoBUus=.814cd82d-7319-4737-944c-ec01f0158e18@github.com>

On Thu, 29 Feb 2024 23:48:12 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <K9ZF3yU-XSESUSZavX_XERw-_bpsWkRUKOGVuLpZoFQ=.41531c4c-9646-4d4c-893b-fad8fddd24a1@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>
 <K9ZF3yU-XSESUSZavX_XERw-_bpsWkRUKOGVuLpZoFQ=.41531c4c-9646-4d4c-893b-fad8fddd24a1@github.com>
Message-ID: <IwJ2NAoYsvHHiACN3olHi2a3Ha6aPrOD5R89wpOH4lc=.8f034538-d244-49da-9d92-c221b9ae9fd7@github.com>

On Fri, 8 Mar 2024 17:30:21 GMT, Anthony Vanelverdinghe <duke at openjdk.org> 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: <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>
Message-ID: <0oONdOJMuG5WpoiQ70jDjgPuhyCUtU4-m-j03ZCRGu8=.7e2e51e4-126f-4114-8238-a24fd1e5d4f4@github.com>

On Thu, 7 Mar 2024 22:46:06 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <Xapo3EQgEEPO6-c6mDAZ_rWpXrXwlD_cEUoGJDzooPU=.bacecfd1-79b1-4cf1-aba2-b7b2530c06d4@github.com>
References: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
 <8SqVgv3h7KV5HmS73vh1hH12BW5Y9U45aNg5PlPvQZs=.61a71b66-0811-4b8f-b96c-cf2d41b54912@github.com>
 <MR35wMmbTnppMe9F6CzuUW6JFw34XfI8HYWt5L5uNBc=.70a21e7b-a9c4-4ac1-a622-eb87daa2f311@github.com>
 <Xapo3EQgEEPO6-c6mDAZ_rWpXrXwlD_cEUoGJDzooPU=.bacecfd1-79b1-4cf1-aba2-b7b2530c06d4@github.com>
Message-ID: <J8BjmRltLvMAU7utKhsTu5zfVhw1ZENIIO2b7sErGYU=.48d5cd90-5649-4dc5-b74c-e9d0c1bf3f19@github.com>

On Mon, 11 Mar 2024 19:00:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
References: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
Message-ID: <gWvcpdLVhNq86cI2hz3JpTtaV1HRYHixCk-NjVb6Xw0=.80729a5c-ca7c-4a0f-a295-6d336131fddf@github.com>

> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
Message-ID: <y850YrusWo5Vhutgjof_rcFGKxdNNpz0RHJF_MHaKpU=.c628aa99-0400-4f0f-aad9-ea3e35e471c4@github.com>

> 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: <RED03_23-9fDt5pKBfgAtc_o2TJDxZ16IGaNIWoBUus=.814cd82d-7319-4737-944c-ec01f0158e18@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <RED03_23-9fDt5pKBfgAtc_o2TJDxZ16IGaNIWoBUus=.814cd82d-7319-4737-944c-ec01f0158e18@github.com>
Message-ID: <ocTzqrb9VodrxUIxFRWw0HqQTaGSkmCO4V4PlUWUVD8=.45c2f904-b9af-40ef-96ad-f3ce238bc9ae@github.com>

On Mon, 11 Mar 2024 19:17:08 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
 <2QIPzuMbsSh7PMFouw5_uco80bECTFk3B6f8X_ghBGo=.f8647c6f-329a-4dcd-81cb-bc6f72d5a657@github.com>
Message-ID: <rNZ4Fp43f9KSd7UBu3CqenSJm2-M1Fe1BzUJfKJW6Nc=.fb0c3253-58ed-4c37-bc96-13923dfcc5ca@github.com>

On Mon, 11 Mar 2024 21:48:15 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <y850YrusWo5Vhutgjof_rcFGKxdNNpz0RHJF_MHaKpU=.c628aa99-0400-4f0f-aad9-ea3e35e471c4@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <y850YrusWo5Vhutgjof_rcFGKxdNNpz0RHJF_MHaKpU=.c628aa99-0400-4f0f-aad9-ea3e35e471c4@github.com>
Message-ID: <frRdGvnlx8jRr7ywt_8xpoQabEjw9Q17unWCmY4BF6o=.6e11dec7-3391-49a6-bb89-fc4cec3ef48d@github.com>

On Mon, 11 Mar 2024 22:44:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <rNZ4Fp43f9KSd7UBu3CqenSJm2-M1Fe1BzUJfKJW6Nc=.fb0c3253-58ed-4c37-bc96-13923dfcc5ca@github.com>
References: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
 <2QIPzuMbsSh7PMFouw5_uco80bECTFk3B6f8X_ghBGo=.f8647c6f-329a-4dcd-81cb-bc6f72d5a657@github.com>
 <rNZ4Fp43f9KSd7UBu3CqenSJm2-M1Fe1BzUJfKJW6Nc=.fb0c3253-58ed-4c37-bc96-13923dfcc5ca@github.com>
Message-ID: <qfBKASJ2qisBivWY-QIMqhi47JDVCyUo9Ufpnpbo0ys=.b23ed30a-009a-4b21-bf3e-52c0db02b67f@github.com>

On Tue, 12 Mar 2024 07:11:40 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <frRdGvnlx8jRr7ywt_8xpoQabEjw9Q17unWCmY4BF6o=.6e11dec7-3391-49a6-bb89-fc4cec3ef48d@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <y850YrusWo5Vhutgjof_rcFGKxdNNpz0RHJF_MHaKpU=.c628aa99-0400-4f0f-aad9-ea3e35e471c4@github.com>
 <frRdGvnlx8jRr7ywt_8xpoQabEjw9Q17unWCmY4BF6o=.6e11dec7-3391-49a6-bb89-fc4cec3ef48d@github.com>
Message-ID: <MYEVmNXMY6deJ52v1HEGwrLeWhqEeU5gXoJUWXZpSY8=.f457b479-d856-4322-8d83-ddbe30eee18e@github.com>

On Tue, 12 Mar 2024 07:36:45 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <MYEVmNXMY6deJ52v1HEGwrLeWhqEeU5gXoJUWXZpSY8=.f457b479-d856-4322-8d83-ddbe30eee18e@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <y850YrusWo5Vhutgjof_rcFGKxdNNpz0RHJF_MHaKpU=.c628aa99-0400-4f0f-aad9-ea3e35e471c4@github.com>
 <frRdGvnlx8jRr7ywt_8xpoQabEjw9Q17unWCmY4BF6o=.6e11dec7-3391-49a6-bb89-fc4cec3ef48d@github.com>
 <MYEVmNXMY6deJ52v1HEGwrLeWhqEeU5gXoJUWXZpSY8=.f457b479-d856-4322-8d83-ddbe30eee18e@github.com>
Message-ID: <kcb0Biun7RXF80YUgdg2yT_9a7BbY1WUoMeYdhZNJLs=.f4aee601-7133-4e85-90c8-295f456c71e8@github.com>

On Tue, 12 Mar 2024 16:20:26 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
Message-ID: <sIQNCPaI-IYFkBPph0lbqhYjU5FnVwDvCPLKBbR3sys=.1b8b872a-c683-45da-8e72-a191a6b29959@github.com>

> 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: <kcb0Biun7RXF80YUgdg2yT_9a7BbY1WUoMeYdhZNJLs=.f4aee601-7133-4e85-90c8-295f456c71e8@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <y850YrusWo5Vhutgjof_rcFGKxdNNpz0RHJF_MHaKpU=.c628aa99-0400-4f0f-aad9-ea3e35e471c4@github.com>
 <frRdGvnlx8jRr7ywt_8xpoQabEjw9Q17unWCmY4BF6o=.6e11dec7-3391-49a6-bb89-fc4cec3ef48d@github.com>
 <MYEVmNXMY6deJ52v1HEGwrLeWhqEeU5gXoJUWXZpSY8=.f457b479-d856-4322-8d83-ddbe30eee18e@github.com>
 <kcb0Biun7RXF80YUgdg2yT_9a7BbY1WUoMeYdhZNJLs=.f4aee601-7133-4e85-90c8-295f456c71e8@github.com>
Message-ID: <DDjqTnZjLab28He-zJi6Vl0ZOpBb3ymo00poLf8JQS0=.8e278910-c1ea-4f8c-af0e-700bbfb8a8b9@github.com>

On Tue, 12 Mar 2024 16:32:38 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
References: <yHEfSzHYk9ZwP_TExoaboj2t0gjDIZy5Pnq0oaTKMCQ=.bda0a024-e516-4636-8e63-a24f8885b1a7@github.com>
Message-ID: <gwo_a2dVxjfpAGu9WTyas7-ZLnLZ5s3mQdTnWo1ggbw=.1141eddc-b7be-4a70-8005-21094020b575@github.com>

On Thu, 29 Feb 2024 23:54:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org>
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: <DDjqTnZjLab28He-zJi6Vl0ZOpBb3ymo00poLf8JQS0=.8e278910-c1ea-4f8c-af0e-700bbfb8a8b9@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <y850YrusWo5Vhutgjof_rcFGKxdNNpz0RHJF_MHaKpU=.c628aa99-0400-4f0f-aad9-ea3e35e471c4@github.com>
 <frRdGvnlx8jRr7ywt_8xpoQabEjw9Q17unWCmY4BF6o=.6e11dec7-3391-49a6-bb89-fc4cec3ef48d@github.com>
 <MYEVmNXMY6deJ52v1HEGwrLeWhqEeU5gXoJUWXZpSY8=.f457b479-d856-4322-8d83-ddbe30eee18e@github.com>
 <kcb0Biun7RXF80YUgdg2yT_9a7BbY1WUoMeYdhZNJLs=.f4aee601-7133-4e85-90c8-295f456c71e8@github.com>
 <DDjqTnZjLab28He-zJi6Vl0ZOpBb3ymo00poLf8JQS0=.8e278910-c1ea-4f8c-af0e-700bbfb8a8b9@github.com>
Message-ID: <D1S4h5FxIea1QLqO5dxznLMgp9Mcx_XJZJYornAbqeU=.b54c8f47-2bcd-475c-9e2f-364e43e061ac@github.com>

On Tue, 12 Mar 2024 18:06:22 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
Message-ID: <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>

> 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: <D1S4h5FxIea1QLqO5dxznLMgp9Mcx_XJZJYornAbqeU=.b54c8f47-2bcd-475c-9e2f-364e43e061ac@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <y850YrusWo5Vhutgjof_rcFGKxdNNpz0RHJF_MHaKpU=.c628aa99-0400-4f0f-aad9-ea3e35e471c4@github.com>
 <frRdGvnlx8jRr7ywt_8xpoQabEjw9Q17unWCmY4BF6o=.6e11dec7-3391-49a6-bb89-fc4cec3ef48d@github.com>
 <MYEVmNXMY6deJ52v1HEGwrLeWhqEeU5gXoJUWXZpSY8=.f457b479-d856-4322-8d83-ddbe30eee18e@github.com>
 <kcb0Biun7RXF80YUgdg2yT_9a7BbY1WUoMeYdhZNJLs=.f4aee601-7133-4e85-90c8-295f456c71e8@github.com>
 <DDjqTnZjLab28He-zJi6Vl0ZOpBb3ymo00poLf8JQS0=.8e278910-c1ea-4f8c-af0e-700bbfb8a8b9@github.com>
 <D1S4h5FxIea1QLqO5dxznLMgp9Mcx_XJZJYornAbqeU=.b54c8f47-2bcd-475c-9e2f-364e43e061ac@github.com>
Message-ID: <p9I45i4r3o6LJClmlebEvQAoHawypN-CPcrHKduMIqo=.bb0840db-2318-415b-9252-e376f683ebd8@github.com>

On Tue, 12 Mar 2024 18:09:53 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <NmZH8BzkPWbrvTyb8QjPvE4PSC9k8UbmiWk9rW-1Svw=.1fc046cb-b404-4467-9484-45453efa0b77@github.com>
 <zGHpiyMAov9JdQqMmkoq2Byi-2lF3WmAvHJKid3oUak=.8eebabc6-09ca-42e5-b631-720befe2ac14@github.com>
Message-ID: <a_2atTUxIb447RLQ6cjznYxOdeSion5-hjFvx_sH-hg=.85b3f00f-4643-4fdc-a5bd-17f0066d7763@github.com>

On Thu, 7 Mar 2024 17:00:19 GMT, Roger Riggs <rriggs at openjdk.org> 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <ZtRi7tWcXz5LpzKyhuagg71LL4iJ3nrrOC5eySqtkrA=.f1dfa798-eed0-493e-9151-cca3506c7f9a@github.com>

> 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: <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <T6bFUtCL40VKYJPsQjRoTPHqjDHpi1Bv3664aTZS0yk=.4a88127d-241b-4230-a0bf-6c8c14443afe@github.com>
Message-ID: <8xt5LK4UrHSxFQ6FpBY99kpgRLZ_nQmyT8wL51o4SCU=.a58d9b9d-4b9f-4c73-9396-c504a53c2fec@github.com>

On Thu, 7 Mar 2024 22:46:06 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
Message-ID: <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com>

On Tue, 12 Mar 2024 22:09:27 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
 <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com>
Message-ID: <Laamm5kiYe6HwZRtx0r194u5oYHRhrHrRGY0-B-wh54=.8d43eb7b-74f9-4ebb-a623-6f129d20a5bd@github.com>

On Wed, 13 Mar 2024 07:21:35 GMT, Alan Bateman <alanb at openjdk.org> 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: <Laamm5kiYe6HwZRtx0r194u5oYHRhrHrRGY0-B-wh54=.8d43eb7b-74f9-4ebb-a623-6f129d20a5bd@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
 <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com>
 <Laamm5kiYe6HwZRtx0r194u5oYHRhrHrRGY0-B-wh54=.8d43eb7b-74f9-4ebb-a623-6f129d20a5bd@github.com>
Message-ID: <rxVumgYrqVlzRBRwnrddfguG_fAEhWZtq6JltO3gU38=.f32eff39-96f3-4f57-af42-094f5f99564b@github.com>

On Wed, 13 Mar 2024 15:40:32 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <rxVumgYrqVlzRBRwnrddfguG_fAEhWZtq6JltO3gU38=.f32eff39-96f3-4f57-af42-094f5f99564b@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
 <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com>
 <Laamm5kiYe6HwZRtx0r194u5oYHRhrHrRGY0-B-wh54=.8d43eb7b-74f9-4ebb-a623-6f129d20a5bd@github.com>
 <rxVumgYrqVlzRBRwnrddfguG_fAEhWZtq6JltO3gU38=.f32eff39-96f3-4f57-af42-094f5f99564b@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 <alanb at openjdk.org> 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: <ZtRi7tWcXz5LpzKyhuagg71LL4iJ3nrrOC5eySqtkrA=.f1dfa798-eed0-493e-9151-cca3506c7f9a@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <ZtRi7tWcXz5LpzKyhuagg71LL4iJ3nrrOC5eySqtkrA=.f1dfa798-eed0-493e-9151-cca3506c7f9a@github.com>
Message-ID: <qqbtaGD7MoGaV8FoHyNj_ArOjo8GRtOHZY0m3xCEyrI=.ba87fd6f-5e07-4f10-9c07-ee72995e18f4@github.com>

On Tue, 12 Mar 2024 23:00:45 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
Message-ID: <Duj5O6JuzzU0b7Q6scCHEg7WshEyNgV9cq4-drlhHfw=.e9535403-aa21-4ab3-891c-f0b3bb4ccfba@github.com>

> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
 <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com>
 <Laamm5kiYe6HwZRtx0r194u5oYHRhrHrRGY0-B-wh54=.8d43eb7b-74f9-4ebb-a623-6f129d20a5bd@github.com>
 <rxVumgYrqVlzRBRwnrddfguG_fAEhWZtq6JltO3gU38=.f32eff39-96f3-4f57-af42-094f5f99564b@github.com>
 <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com>
Message-ID: <Idv0WyO3lajMlQzvDD2PBRiG_viMBOFLVClcuJYr8Oc=.9f1dd5d6-3aec-4549-8c48-c11e6ea1c2e1@github.com>

On Wed, 13 Mar 2024 16:00:04 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <Idv0WyO3lajMlQzvDD2PBRiG_viMBOFLVClcuJYr8Oc=.9f1dd5d6-3aec-4549-8c48-c11e6ea1c2e1@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
 <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com>
 <Laamm5kiYe6HwZRtx0r194u5oYHRhrHrRGY0-B-wh54=.8d43eb7b-74f9-4ebb-a623-6f129d20a5bd@github.com>
 <rxVumgYrqVlzRBRwnrddfguG_fAEhWZtq6JltO3gU38=.f32eff39-96f3-4f57-af42-094f5f99564b@github.com>
 <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com>
 <Idv0WyO3lajMlQzvDD2PBRiG_viMBOFLVClcuJYr8Oc=.9f1dd5d6-3aec-4549-8c48-c11e6ea1c2e1@github.com>
Message-ID: <seNaHhJa05VTQXOZDFv3ZVapo5EVu4TMWe6PJv-mBCY=.ca327f67-d8ca-43c5-b30b-03603c0ce419@github.com>

On Wed, 13 Mar 2024 17:37:17 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <seNaHhJa05VTQXOZDFv3ZVapo5EVu4TMWe6PJv-mBCY=.ca327f67-d8ca-43c5-b30b-03603c0ce419@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
 <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com>
 <Laamm5kiYe6HwZRtx0r194u5oYHRhrHrRGY0-B-wh54=.8d43eb7b-74f9-4ebb-a623-6f129d20a5bd@github.com>
 <rxVumgYrqVlzRBRwnrddfguG_fAEhWZtq6JltO3gU38=.f32eff39-96f3-4f57-af42-094f5f99564b@github.com>
 <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com>
 <Idv0WyO3lajMlQzvDD2PBRiG_viMBOFLVClcuJYr8Oc=.9f1dd5d6-3aec-4549-8c48-c11e6ea1c2e1@github.com>
 <seNaHhJa05VTQXOZDFv3ZVapo5EVu4TMWe6PJv-mBCY=.ca327f67-d8ca-43c5-b30b-03603c0ce419@github.com>
Message-ID: <dEZ9sw5CpgOJSNZJJIWdf5dq8vqFq2B2InCSletipeo=.098d7346-2f7f-4261-99f4-ac8e894465aa@github.com>

On Wed, 13 Mar 2024 17:50:31 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <dEZ9sw5CpgOJSNZJJIWdf5dq8vqFq2B2InCSletipeo=.098d7346-2f7f-4261-99f4-ac8e894465aa@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <QRYMWYLw0h7FGTf5k4zepcTeU3PcfKsba89wLYpZZzU=.88e7f900-125c-45f9-9943-39954abca256@github.com>
 <39TAeOCxMg7JRyQIFBNO0F6McJWlFL3kRy9pSuIpBDI=.64d5d906-6846-4473-a340-e0fd66a46c56@github.com>
 <Laamm5kiYe6HwZRtx0r194u5oYHRhrHrRGY0-B-wh54=.8d43eb7b-74f9-4ebb-a623-6f129d20a5bd@github.com>
 <rxVumgYrqVlzRBRwnrddfguG_fAEhWZtq6JltO3gU38=.f32eff39-96f3-4f57-af42-094f5f99564b@github.com>
 <9n05AmnE5WLlZfV7AfYTp-N97xRvxGUSL5X45-JDqdc=.1447f895-1d96-41e9-8639-a59ecd65b977@github.com>
 <Idv0WyO3lajMlQzvDD2PBRiG_viMBOFLVClcuJYr8Oc=.9f1dd5d6-3aec-4549-8c48-c11e6ea1c2e1@github.com>
 <seNaHhJa05VTQXOZDFv3ZVapo5EVu4TMWe6PJv-mBCY=.ca327f67-d8ca-43c5-b30b-03603c0ce419@github.com>
 <dEZ9sw5CpgOJSNZJJIWdf5dq8vqFq2B2InCSletipeo=.098d7346-2f7f-4261-99f4-ac8e894465aa@github.com>
Message-ID: <wrOA-KXqouZpyF40qKPvEJZdbUlwAMe3wB6eWmtcV4c=.bdd0c321-73c3-4f58-a9e6-aef7fdde40d7@github.com>

On Wed, 13 Mar 2024 19:27:53 GMT, Alan Bateman <alanb at openjdk.org> 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: <ZtRi7tWcXz5LpzKyhuagg71LL4iJ3nrrOC5eySqtkrA=.f1dfa798-eed0-493e-9151-cca3506c7f9a@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <ZtRi7tWcXz5LpzKyhuagg71LL4iJ3nrrOC5eySqtkrA=.f1dfa798-eed0-493e-9151-cca3506c7f9a@github.com>
Message-ID: <eTA_r2dSemYpwIvFAjBUxQytxhLtZcbF1E94yY-IzWo=.7812427f-658d-40f9-bf17-9d0bba2181e1@github.com>

On Tue, 12 Mar 2024 23:00:45 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <Duj5O6JuzzU0b7Q6scCHEg7WshEyNgV9cq4-drlhHfw=.e9535403-aa21-4ab3-891c-f0b3bb4ccfba@github.com>
 <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com>
Message-ID: <j8ZTUzl2gDH7Oy70-yQsTxLpRIKQFMtcmGIeMEeYPG4=.45e0a038-46c2-480b-9344-dde4f3b26ad7@github.com>

On Wed, 13 Mar 2024 20:13:24 GMT, Alan Bateman <alanb at openjdk.org> 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: <Duj5O6JuzzU0b7Q6scCHEg7WshEyNgV9cq4-drlhHfw=.e9535403-aa21-4ab3-891c-f0b3bb4ccfba@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <Duj5O6JuzzU0b7Q6scCHEg7WshEyNgV9cq4-drlhHfw=.e9535403-aa21-4ab3-891c-f0b3bb4ccfba@github.com>
Message-ID: <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com>

On Wed, 13 Mar 2024 17:40:27 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <ZtRi7tWcXz5LpzKyhuagg71LL4iJ3nrrOC5eySqtkrA=.f1dfa798-eed0-493e-9151-cca3506c7f9a@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <ZtRi7tWcXz5LpzKyhuagg71LL4iJ3nrrOC5eySqtkrA=.f1dfa798-eed0-493e-9151-cca3506c7f9a@github.com>
Message-ID: <nHlUt9DRF7ojhucr8nK5IswjHjizVXAMEcJIGLs_IqU=.5723058b-f061-4f20-90ee-f658f1855f97@github.com>

On Tue, 12 Mar 2024 23:00:45 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>

> 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: <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
Message-ID: <ZXk5h6soxPYXM80L65W9kjaCarJrwexf-8JrW7GrpDs=.13aa605a-0847-4b4b-9fd0-bc319ffa7c3d@github.com>

On Wed, 13 Mar 2024 23:12:50 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <j8ZTUzl2gDH7Oy70-yQsTxLpRIKQFMtcmGIeMEeYPG4=.45e0a038-46c2-480b-9344-dde4f3b26ad7@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <Duj5O6JuzzU0b7Q6scCHEg7WshEyNgV9cq4-drlhHfw=.e9535403-aa21-4ab3-891c-f0b3bb4ccfba@github.com>
 <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com>
 <j8ZTUzl2gDH7Oy70-yQsTxLpRIKQFMtcmGIeMEeYPG4=.45e0a038-46c2-480b-9344-dde4f3b26ad7@github.com>
Message-ID: <I2Ykdypdm0NZpPomcljo6UNfRFhZHsGLanr4K6U_p8Q=.f5f3df7b-1f24-4c6d-b295-ec0149df27c3@github.com>

On Wed, 13 Mar 2024 20:15:34 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <CAECsnDSd3ZmSHVeoK7YfiDkfSzSq0gRWXrYh5X2j=tMXC1gdKQ@mail.gmail.com>
References: <CAECsnDSd3ZmSHVeoK7YfiDkfSzSq0gRWXrYh5X2j=tMXC1gdKQ@mail.gmail.com>
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: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240314/5bb75c10/attachment.htm>

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: <I2Ykdypdm0NZpPomcljo6UNfRFhZHsGLanr4K6U_p8Q=.f5f3df7b-1f24-4c6d-b295-ec0149df27c3@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
 <Duj5O6JuzzU0b7Q6scCHEg7WshEyNgV9cq4-drlhHfw=.e9535403-aa21-4ab3-891c-f0b3bb4ccfba@github.com>
 <71wQw6EVuXYyEYDqrQlLxCQEBxy9IWxUAF0MalzlqXk=.b74c878e-417a-4f74-8396-5db92a3a7a0d@github.com>
 <j8ZTUzl2gDH7Oy70-yQsTxLpRIKQFMtcmGIeMEeYPG4=.45e0a038-46c2-480b-9344-dde4f3b26ad7@github.com>
 <I2Ykdypdm0NZpPomcljo6UNfRFhZHsGLanr4K6U_p8Q=.f5f3df7b-1f24-4c6d-b295-ec0149df27c3@github.com>
Message-ID: <OnL4xN4_KTDlJrKSwsZCvb-W17v8Mo_0EB2ueQm8ZfY=.79e5c776-763d-45bd-b3af-6f22e902012a@github.com>

On Thu, 14 Mar 2024 07:05:15 GMT, Alan Bateman <alanb at openjdk.org> 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: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
References: <UUeOG8G6zpeav70SqQL4cI_3RWEPqRaBAoPru148zws=.2f09139d-fbf7-4fc1-9212-bb7a9ba1cba6@github.com>
Message-ID: <aadqdfGtpkOLTP1MyhP7tvyAJVFI30e0oLAcJe6wk3g=.58d5470d-0bd1-4f57-9ff9-aad79c308d46@github.com>

On Thu, 29 Feb 2024 23:48:12 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org>
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: <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
Message-ID: <aWErnjTOCAg8ZKzhnK4hjAr5s2Ug92Bl0-7MSW3ir4A=.74fe5cf2-7cee-49ed-98f5-5250e8e3b910@github.com>

On Wed, 13 Mar 2024 23:12:50 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
Message-ID: <8lOBzECjbca5-r9I8jyhVua_BGz6VzQradze3rzKXoY=.6bc9c9ea-cefc-46d2-b64c-3dc965c4888d@github.com>

On Wed, 13 Mar 2024 23:12:50 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <hsyr1yMaLY8vF9TS_rpj_wJQUCaqSk1n0gPyJ-ufCW0=.0701e6a2-df45-4486-b6bf-39be265dce89@github.com>

On Thu, 29 Feb 2024 09:45:35 GMT, Nizar Benalla <duke at openjdk.org> 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: <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
Message-ID: <bpQKmOjjpwyRCEMRrQHLKtUm-_RZQeEvcQvELkSnWDM=.6d9320b7-7818-4482-b85c-599c5f0b187a@github.com>

On Tue, 19 Sep 2023 20:03:57 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
Message-ID: <8E5VOdhiIyY6BzHE44QEi6i_2eK8oMKbgTauVBRmqrY=.3ed2a7e3-b9fb-42c1-965a-13280c98ec59@github.com>

On Wed, 13 Mar 2024 23:12:50 GMT, Brian Burkhalter <bpb at openjdk.org> 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<String>`. 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: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
 <8E5VOdhiIyY6BzHE44QEi6i_2eK8oMKbgTauVBRmqrY=.3ed2a7e3-b9fb-42c1-965a-13280c98ec59@github.com>
Message-ID: <y8YGAT4MF2NNQ_t8MSJH7sfTA9c6nN98tIFDzC3GhkQ=.c0c30a78-d6a9-4c93-b8c7-4cc34e05e060@github.com>

On Fri, 15 Mar 2024 18:10:52 GMT, Anthony Vanelverdinghe <duke at openjdk.org> wrote:

> If so, I believe the return type ought to be `Optional<String>`. 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: <y8YGAT4MF2NNQ_t8MSJH7sfTA9c6nN98tIFDzC3GhkQ=.c0c30a78-d6a9-4c93-b8c7-4cc34e05e060@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
 <8E5VOdhiIyY6BzHE44QEi6i_2eK8oMKbgTauVBRmqrY=.3ed2a7e3-b9fb-42c1-965a-13280c98ec59@github.com>
 <y8YGAT4MF2NNQ_t8MSJH7sfTA9c6nN98tIFDzC3GhkQ=.c0c30a78-d6a9-4c93-b8c7-4cc34e05e060@github.com>
Message-ID: <m_JCrHVBGllxL0vosgIRhnIJQmlNRbVaWA1gA891Ml8=.9b1195a8-eb15-40d5-b9ae-460a5cf1b907@github.com>

On Sat, 16 Mar 2024 11:23:50 GMT, ExE Boss <duke at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <KuFvmtJkJrOnOmzcc5kjHbajtkzMNKQnHpperfTK9LI=.c22ef053-17ec-4ec8-8465-29b8c8eb5ef9@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:

  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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <bAIsgoT0mopCkvsLbpjKe8PxLNB1v_WojMMuq3k8qyA=.5d13138a-1369-4640-a123-8ecf125c65ef@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:

 - 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <Hzb3BRT3YdYFxjfcEng90akTVQkea995UaZPKD5JrDY=.8d9664c8-b366-478b-9552-536d8eaa761c@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:

  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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@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:

  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: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>

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: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <W4H6LMjZxokSSq71NxDkNNbQgPxQKAJ9unepFW6K2sU=.de53b1b9-60b7-4786-925c-9accf7681f7e@github.com>

On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang <bhuang at openjdk.org> 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: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
Message-ID: <XovkM9T-EQ1X2jzj2lvn4IuxeeKVkm6BrBxtqXNBaDE=.e920c3d1-7813-47c0-b32d-0fcb5ffd6a4d@github.com>

On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla <duke at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
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: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
Message-ID: <AzDSHkHxsYiIZjvEbYs9mOtKyeitmU11N82MEW6miEg=.fc52ea51-7905-4cfd-a8e6-0e50e63493f2@github.com>

On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla <duke at openjdk.org> 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: <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@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 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: <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
Message-ID: <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>

On Tue, 19 Mar 2024 11:21:14 GMT, Nizar Benalla <duke at openjdk.org> 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: <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
 <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>
Message-ID: <K6SpdFx7vEtLn0ORV6AVig5Z-0g9-vDUGpL8xlMMxdI=.7f224f25-dd6b-4d00-9e0d-cf76cf6bb8fb@github.com>

On Sat, 16 Mar 2024 00:20:51 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <K6SpdFx7vEtLn0ORV6AVig5Z-0g9-vDUGpL8xlMMxdI=.7f224f25-dd6b-4d00-9e0d-cf76cf6bb8fb@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
 <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>
 <K6SpdFx7vEtLn0ORV6AVig5Z-0g9-vDUGpL8xlMMxdI=.7f224f25-dd6b-4d00-9e0d-cf76cf6bb8fb@github.com>
Message-ID: <HklJY0-bc9olSZa06HvI31hvTu-tSzDJq3851ndtq6k=.d8d874f5-f456-4a88-9e8b-9803b210a71a@github.com>

On Sun, 17 Mar 2024 01:20:17 GMT, Nizar Benalla <duke at openjdk.org> 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: <HklJY0-bc9olSZa06HvI31hvTu-tSzDJq3851ndtq6k=.d8d874f5-f456-4a88-9e8b-9803b210a71a@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
 <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>
 <K6SpdFx7vEtLn0ORV6AVig5Z-0g9-vDUGpL8xlMMxdI=.7f224f25-dd6b-4d00-9e0d-cf76cf6bb8fb@github.com>
 <HklJY0-bc9olSZa06HvI31hvTu-tSzDJq3851ndtq6k=.d8d874f5-f456-4a88-9e8b-9803b210a71a@github.com>
Message-ID: <xTb03h9jOHl392fvK_Tu_3LyXqlMod3dSmd2uLzaJMg=.2fa387a2-6a47-4bd2-b882-ea74520d9896@github.com>

On Mon, 18 Mar 2024 14:02:20 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <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 <duke at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
 <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>
Message-ID: <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>

On Tue, 19 Mar 2024 16:13:49 GMT, Justin Lu <jlu at openjdk.org> 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: <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
 <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>
 <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>
Message-ID: <Tquf1xKBVkshr66HGgVy9yVpl53oCjPH2KrSQYNq1VM=.e2fd363a-7bab-4f78-923a-6c1a153de746@github.com>

On Tue, 19 Mar 2024 17:05:50 GMT, Nizar Benalla <duke at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <GXW2-arZymX_4iLIBbcG608h4-QvxtH8P97lWY-hWeI=.6f57894b-aa5f-423e-b9a9-4f32da6a37a6@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> 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: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>

> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> 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: <YOGk9cUYcFRYOZN1zhy49hIEjqhUfYP_VENHMr5YHLM=.ae609a72-e61a-4830-bcc5-7bf7fdc3c2f5@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 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: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <E9ekmv_5nb6r5rq1GBtSGAtKe8odMuOy153p42a3kzQ=.20d60bba-892c-4566-8323-8a25e10891d8@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <pjgeEs6MaHAk8pv0ZGE9VNEZ1XAm0hVfSUb9WcEilFk=.33042064-905e-4e73-b05b-a246fc581908@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
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: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> 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: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <-LZotlcsvx3EbHNNn0DO-u7HsWB302dYqZ33vFTf0UA=.9728ca78-a90f-4705-8b81-de5c61d342ca@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> 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: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> 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: <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
 <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
Message-ID: <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>

On Tue, 19 Mar 2024 17:59:48 GMT, Nizar Benalla <duke at openjdk.org> 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: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
Message-ID: <AW72Q2T6TyFJRUkyTjV-eZJdV0KUGZ-YFQa_ZatithQ=.bfd1c59b-1823-4c87-aa5f-5473959f4278@github.com>

On Thu, 21 Mar 2024 14:41:36 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
Message-ID: <5fp1NwbiBibdMUnZA8mIj76MLVvTxdA2m_z9IM8dUEc=.28d46052-8e8d-4ede-96ac-5da5d7a568a9@github.com>

On Thu, 21 Mar 2024 15:06:58 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>

> 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: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <H3UoDTth09CIdHaBVX8occDp0THRZY-SI9UrWHnTN0c=.c3e8aaf5-0e94-4599-9862-5a8cdc09f3be@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com>
Message-ID: <OrMrE0Qq8TigtKpb2SMcyaZ2CXZqfGmpHIW61GkpXOo=.90051740-7358-4dd6-a844-8e375d930d37@github.com>

On Wed, 20 Mar 2024 18:04:50 GMT, Nizar Benalla <duke at openjdk.org> 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: <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
 <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
 <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>
Message-ID: <ybe6vfwdT6TWJEIUIvx7aJrcFaEKGNKuoQZZ05Q6k90=.b3b2a78f-80f4-4a4a-9321-42ca44a9eaf2@github.com>

On Thu, 21 Mar 2024 16:50:31 GMT, Justin Lu <jlu at openjdk.org> 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: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <4cUvcPClyJ-k2flHg2HTAheLLeCUKQsee04x-gQ9B5M=.6eefac93-ca3d-435a-990b-27de51410e3c@github.com>

On Tue, 27 Feb 2024 16:28:26 GMT, Nizar Benalla <duke at openjdk.org> 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 <nizar.benalla at oracle.com>
Committer: Justin Lu <jlu at openjdk.org>
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: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dnzll7uMjmAmGD_8ZaudJH1Kw90Dqq-j3TEiABaWSu4=.560e44c6-d426-4799-9fe6-fc04b338ef38@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> 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: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dDrW4l3mQ8774vjN_VH6nQ94gMJSKK5xcEzMpxy_EPU=.8d557a74-6ad1-44ae-ba35-cab23db68f39@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> 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: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>

> 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 <turbanoff at gmail.com>

-------------

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: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>

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: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <EfqP82wv46tkL-lb7QhMgC748W7wJ0dV5KWNWNHaCNg=.a2b9453a-1d9b-41f5-ac0e-b5bf54d77c48@github.com>

On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing <tprinzing at openjdk.org> 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: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <u2efcIPGCJXkSOQMCdqOT3LVLRqW42S-uRuMcwVoPPs=.2975a724-467c-4b62-852a-691b07bfe2d9@github.com>

On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing <tprinzing at openjdk.org> 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: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <5WxpEWPgGFA1cNFyaD0ww5qSGnC1a1axgcgzBcH22CA=.6b54905a-92fd-4d2c-84cf-ffabd88be2c0@github.com>

On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing <tprinzing at openjdk.org> 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