From bhuang at openjdk.org  Wed Feb  1 17:40:50 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 1 Feb 2023 17:40:50 GMT
Subject: RFR: JDK-8300912: Update java/nio/MappedByteBuffer/PmemTest.java
 to run on x86_64 only
In-Reply-To: <5Y-l74ZQl-HHVYlRIjGRQo7DmGxsFnzK6GovUJNIl_g=.ebf91943-3532-440d-8bbc-428393dd7eb6@github.com>
References: <iCsNXiV_PMMic10mqC5Yx0Xw4nJl5mOKxb-37QrR03E=.1542ef36-70af-43c8-ae1b-9a99eaf2a5da@github.com>
 <5Y-l74ZQl-HHVYlRIjGRQo7DmGxsFnzK6GovUJNIl_g=.ebf91943-3532-440d-8bbc-428393dd7eb6@github.com>
Message-ID: <WHedN9aW93W-WRALqnsCsIuB_ptFMBrv70ATS6-Emjw=.e7b21b7e-0287-4820-96e1-fd34e93913a5@github.com>

On Tue, 31 Jan 2023 20:40:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This task is created to update jtreg test to run on x86 only because pmem emulation is only supported on x86. For other architectures with external NVRAM, run test with java PmemTest.
>
> Maybe @adinn could comment on this as I thought this test was meant for both x64 and aarch64.

@AlanBateman Yes, this test was for both x64 and aarch64. The changes here are meant to not run test with jtreg on non-x64 system. This is because our manual test vendor can only support pmem emulation on x64 systems for this test. The test will always fail on aarch64 Linux systems. For someone who wants to test pmem with an external device, it is always allowed to compile and run the test manually.

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

PR: https://git.openjdk.org/jdk/pull/12352

From duke at openjdk.org  Wed Feb  1 18:30:32 2023
From: duke at openjdk.org (duke)
Date: Wed, 1 Feb 2023 18:30:32 GMT
Subject: Withdrawn: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
Message-ID: <oHM1mEg08deCDGEhcW8iIm-ahQzao_64VFs1tocVTVs=.14b36ce6-e97f-4e10-a0c1-cf4a1d8d3aec@github.com>

On Fri, 2 Sep 2022 07:54:32 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
> 
> Some things of note:
> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
> 
> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
> 
> ### Testing
> 
> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
> * Also verified that new tests pass on Linux and Windows.
> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10140

From mik3hall at gmail.com  Wed Feb  1 23:56:07 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 1 Feb 2023 17:56:07 -0600
Subject: Withdrawn: 8293067: (fs) Implement WatchService using system
 library (macOS)
In-Reply-To: <oHM1mEg08deCDGEhcW8iIm-ahQzao_64VFs1tocVTVs=.14b36ce6-e97f-4e10-a0c1-cf4a1d8d3aec@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <oHM1mEg08deCDGEhcW8iIm-ahQzao_64VFs1tocVTVs=.14b36ce6-e97f-4e10-a0c1-cf4a1d8d3aec@github.com>
Message-ID: <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>



> On Feb 1, 2023, at 12:30 PM, duke <duke at openjdk.org> wrote:
> 
> On Fri, 2 Sep 2022 07:54:32 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:
> 
>> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
>> 
>> Some things of note:
>> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
>> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
>> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
>> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
>> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
>> 
>> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
>> 
>> ### Testing
>> 
>> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
>> * Also verified that new tests pass on Linux and Windows.
>> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.
> 
> This pull request has been closed without being integrated.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10140

Is there any chance this will be made available in some other way?


From mkartashev at openjdk.org  Fri Feb  3 11:53:20 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 3 Feb 2023 11:53:20 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>
Message-ID: <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>

On Thu, 2 Feb 2023 15:33:40 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> Is there any chance this will be made available in some other way?

[JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime) has FSEvents-based implementation of WatchService on macOS.

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

PR: https://git.openjdk.org/jdk/pull/10140

From alanb at openjdk.org  Fri Feb  3 12:05:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Feb 2023 12:05:21 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>
 <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>
Message-ID: <rjlOHBP_VH-E4qvlnDaDcl1g__eEMfPiTGfFA--HYfA=.70ce080e-f48a-44c8-a87c-f00f5a1804d8@github.com>

On Fri, 3 Feb 2023 11:49:53 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime) has FSEvents-based implementation of WatchService on macOS.

Is this similar to what was proposed here, I'm curious if the same issues were encountered when running the tests across a wider range of macOS releases.

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

PR: https://git.openjdk.org/jdk/pull/10140

From mkartashev at openjdk.org  Fri Feb  3 14:10:29 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 3 Feb 2023 14:10:29 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <rjlOHBP_VH-E4qvlnDaDcl1g__eEMfPiTGfFA--HYfA=.70ce080e-f48a-44c8-a87c-f00f5a1804d8@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>
 <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>
 <rjlOHBP_VH-E4qvlnDaDcl1g__eEMfPiTGfFA--HYfA=.70ce080e-f48a-44c8-a87c-f00f5a1804d8@github.com>
Message-ID: <Kr_bchs-__BOwcy-kSX9AudXYWpd0ET3bp331yKgaJg=.36e1d9cd-cc96-457f-82e7-fbd1a9e07df4@github.com>

On Fri, 3 Feb 2023 12:01:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Is there any chance this will be made available in some other way?
>> 
>> [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime) has FSEvents-based implementation of WatchService on macOS.
>
>> [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime) has FSEvents-based implementation of WatchService on macOS.
> 
> Is this similar to what was proposed here, I'm curious if the same issues were encountered when running the tests across a wider range of macOS releases.

@AlanBateman It is the implementation this one was based upon. No _known_ bugs exist there at this moment in time (tests were run on IntelliJ infrastructure, of course).

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

PR: https://git.openjdk.org/jdk/pull/10140

From mik3hall at gmail.com  Fri Feb  3 14:37:42 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 3 Feb 2023 08:37:42 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>
 <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>
Message-ID: <38BC3792-48A6-4061-A75A-D92097FC220E@gmail.com>



> On Feb 3, 2023, at 5:53 AM, Maxim Kartashev <mkartashev at openjdk.org> wrote:
> 
> On Thu, 2 Feb 2023 15:33:40 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> Is there any chance this will be made available in some other way?
> 
> [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime) has FSEvents-based implementation of WatchService on macOS.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10140

Thanks,
I have code that mostly passes through to the default OS/X file system provider but includes some extensions to expose some of the OS/X native api?s. 
Not getting a lot of use I know of, but I run some other code off of it myself.
It lacks a WatchService ,my own attempt at a kqueue one for that coming up short.
So no actual native WatchService, which seemed a shame. 
I may try to make use of yours.

From bpb at openjdk.org  Fri Feb  3 16:46:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 3 Feb 2023 16:46:19 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <Kr_bchs-__BOwcy-kSX9AudXYWpd0ET3bp331yKgaJg=.36e1d9cd-cc96-457f-82e7-fbd1a9e07df4@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>
 <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>
 <rjlOHBP_VH-E4qvlnDaDcl1g__eEMfPiTGfFA--HYfA=.70ce080e-f48a-44c8-a87c-f00f5a1804d8@github.com>
 <Kr_bchs-__BOwcy-kSX9AudXYWpd0ET3bp331yKgaJg=.36e1d9cd-cc96-457f-82e7-fbd1a9e07df4@github.com>
Message-ID: <QCPA_lXYN-5HgvOPL_dI1YO-gM8rZBydZC_Pf5YAy1Q=.ab8a9146-67be-4bd9-bb01-2514543519da@github.com>

On Fri, 3 Feb 2023 14:07:36 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>>> [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime) has FSEvents-based implementation of WatchService on macOS.
>> 
>> Is this similar to what was proposed here, I'm curious if the same issues were encountered when running the tests across a wider range of macOS releases.
>
> @AlanBateman It is the implementation this one was based upon. No _known_ bugs exist there at this moment in time (tests were run on IntelliJ infrastructure, of course).

@mkartashev Do you intend to continue work on this PR? If not, then we could potentially take over the work if that is acceptable.

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

PR: https://git.openjdk.org/jdk/pull/10140

From bpb at openjdk.org  Fri Feb  3 22:06:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 3 Feb 2023 22:06:20 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <38BC3792-48A6-4061-A75A-D92097FC220E@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <38BC3792-48A6-4061-A75A-D92097FC220E@gmail.com>
Message-ID: <ltZy3e6bHkjQZdjeUcfcFNHGTK7H-3xJnGYrGbV_fds=.c5118489-0992-427f-b11e-bf01d484f7e6@github.com>

On Fri, 3 Feb 2023 21:54:37 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> It lacks a WatchService ,my own attempt at a kqueue one for that coming up short.

As was previously discussed (I think) I don't believe that a `kqueue` implementation is feasible as it will eventually run out of file descriptors. This is specifically due to `MODIFY` which cannot be detected without having an open file descriptor for each monitored file.

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

PR: https://git.openjdk.org/jdk/pull/10140

From bpb at openjdk.org  Sat Feb  4 00:09:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 4 Feb 2023 00:09:36 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix
Message-ID: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>

Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..

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

Commit messages:
 - 8298478: (fs) Path.of should allow input to include long path prefix

Changes: https://git.openjdk.org/jdk/pull/12423/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12423&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298478
  Stats: 23 lines in 2 files changed: 20 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12423.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12423/head:pull/12423

PR: https://git.openjdk.org/jdk/pull/12423

From mkartashev at openjdk.org  Sat Feb  4 07:23:10 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Sat, 4 Feb 2023 07:23:10 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <Kr_bchs-__BOwcy-kSX9AudXYWpd0ET3bp331yKgaJg=.36e1d9cd-cc96-457f-82e7-fbd1a9e07df4@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>
 <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>
 <rjlOHBP_VH-E4qvlnDaDcl1g__eEMfPiTGfFA--HYfA=.70ce080e-f48a-44c8-a87c-f00f5a1804d8@github.com>
 <Kr_bchs-__BOwcy-kSX9AudXYWpd0ET3bp331yKgaJg=.36e1d9cd-cc96-457f-82e7-fbd1a9e07df4@github.com>
Message-ID: <xJ0bX4Y8Iu8GrPNT0DgowyBdGnufjRPFF0iLw59R2eM=.9d6cf36a-7752-4faf-84e3-98a4b92ef7e2@github.com>

On Fri, 3 Feb 2023 14:07:36 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>>> [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime) has FSEvents-based implementation of WatchService on macOS.
>> 
>> Is this similar to what was proposed here, I'm curious if the same issues were encountered when running the tests across a wider range of macOS releases.
>
> @AlanBateman It is the implementation this one was based upon. No _known_ bugs exist there at this moment in time (tests were run on IntelliJ infrastructure, of course).

> @mkartashev Do you intend to continue work on this PR? If not, then we could potentially take over the work if that is acceptable.

I plan to have a shot at using newer (not declared deprecated) API for scheduling the event stream. If that fails, this implementation is up for grabs for all I care.

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

PR: https://git.openjdk.org/jdk/pull/10140

From mik3hall at gmail.com  Sat Feb  4 07:34:18 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 4 Feb 2023 01:34:18 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <ltZy3e6bHkjQZdjeUcfcFNHGTK7H-3xJnGYrGbV_fds=.c5118489-0992-427f-b11e-bf01d484f7e6@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <38BC3792-48A6-4061-A75A-D92097FC220E@gmail.com>
 <ltZy3e6bHkjQZdjeUcfcFNHGTK7H-3xJnGYrGbV_fds=.c5118489-0992-427f-b11e-bf01d484f7e6@github.com>
Message-ID: <94082354-4799-4D7A-BCDD-AD30EDD73948@gmail.com>



> On Feb 3, 2023, at 4:06 PM, Brian Burkhalter <bpb at openjdk.org> wrote:
> 
> On Fri, 3 Feb 2023 21:54:37 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> It lacks a WatchService ,my own attempt at a kqueue one for that coming up short.
> 
> As was previously discussed (I think) I don't believe that a `kqueue` implementation is feasible as it will eventually run out of file descriptors. This is specifically due to `MODIFY` which cannot be detected without having an open file descriptor for each monitored file.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10140

This was some time ago and I have no current intention to continue work on that although I?m not sure I ever removed the code from the project.


From mik3hall at gmail.com  Sat Feb  4 07:40:17 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 4 Feb 2023 01:40:17 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <xJ0bX4Y8Iu8GrPNT0DgowyBdGnufjRPFF0iLw59R2eM=.9d6cf36a-7752-4faf-84e3-98a4b92ef7e2@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <04E3F627-6690-440C-A715-8DCD846DBAE1@gmail.com>
 <MMZpLL9FNVj_lDY51KGda49ngqvJamVHc8vyJ6OR0gM=.5c427b88-d91f-4c3a-a41e-eb6c04ede53d@github.com>
 <rjlOHBP_VH-E4qvlnDaDcl1g__eEMfPiTGfFA--HYfA=.70ce080e-f48a-44c8-a87c-f00f5a1804d8@github.com>
 <Kr_bchs-__BOwcy-kSX9AudXYWpd0ET3bp331yKgaJg=.36e1d9cd-cc96-457f-82e7-fbd1a9e07df4@github.com>
 <xJ0bX4Y8Iu8GrPNT0DgowyBdGnufjRPFF0iLw59R2eM=.9d6cf36a-7752-4faf-84e3-98a4b92ef7e2@github.com>
Message-ID: <4218710C-D702-4F94-A172-18AE41977215@gmail.com>



> On Feb 4, 2023, at 1:23 AM, Maxim Kartashev <mkartashev at openjdk.org> wrote:
> 
> On Fri, 3 Feb 2023 14:07:36 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:
> 
>>>> [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime) has FSEvents-based implementation of WatchService on macOS.
>>> 
>>> Is this similar to what was proposed here, I'm curious if the same issues were encountered when running the tests across a wider range of macOS releases.
>> 
>> @AlanBateman It is the implementation this one was based upon. No _known_ bugs exist there at this moment in time (tests were run on IntelliJ infrastructure, of course).
> 
>> @mkartashev Do you intend to continue work on this PR? If not, then we could potentially take over the work if that is acceptable.
> 
> I plan to have a shot at using newer (not declared deprecated) API for scheduling the event stream. If that fails, this implementation is up for grabs for all I care.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10140

As I remember working on this was difficult because Maxim and I weren?t able to reproduce whatever errors the jdk testing framework was getting.

If you say you are done, and the PR has been closed by openjdk, I?ll grab a copy. It would probably be easier than trying to extract it from the GitHub project you posted.

How will your changes be tested if the PR has been closed?


From alanb at openjdk.org  Sat Feb  4 07:56:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 4 Feb 2023 07:56:48 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix
In-Reply-To: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
Message-ID: <OwnP6_RbK1_zsFbdS86-PipJKUQj8PXfexYQqoyJWFs=.84cbc24a-40c3-4acb-a53f-2cca929bb821@github.com>

On Sat, 4 Feb 2023 00:03:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..

I think there is a bit more to this, what would we expect from `Path.of("\\\?\")` for example? I think the eventual solution will strip the prefix, parse the remainder, and then check the result path type with the prefix. For example, if the resulting path type is relative then it should be rejected. If the prefix is `\\\?\` and the parsed remaining is a UNC then maybe it should be rejected? So I think there is a bit more to this can just stripping the prefix.

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

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 00:23:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 00:23:58 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v2]
In-Reply-To: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
Message-ID: <2tJTe4YyVh4scGpg-oedUPrE6hIHUUE2Dujo2kG0aYM=.bf7a3d41-7085-4481-a173-7e967d592e5b@github.com>

> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8298478: Verify parsed type is acceptable for prefix type; add some cases to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12423/files
  - new: https://git.openjdk.org/jdk/pull/12423/files/34bb5b56..89d757f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12423&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12423&range=00-01

  Stats: 59 lines in 2 files changed: 42 ins; 13 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12423.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12423/head:pull/12423

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 00:31:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 00:31:57 GMT
Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v3]
In-Reply-To: <kkya6Z44qUjXdlkV4qZ_ikfPQI5IE-Uu6wwuE11uM8M=.4cc7d7b0-a8be-429f-b46e-b200992c2a94@github.com>
References: <zMvOgJCwfHo7TDN0A_iT-NDEha0alAhOZj2LlCMQuzI=.83b43e96-fe35-4a56-896c-382ff454db4f@github.com>
 <kkya6Z44qUjXdlkV4qZ_ikfPQI5IE-Uu6wwuE11uM8M=.4cc7d7b0-a8be-429f-b46e-b200992c2a94@github.com>
Message-ID: <i5ZuKEgWotYS904hui3LZ94p8CZ9Y8lHwzwVJGjY6BE=.ff76210f-c2b7-43d3-9f80-b931eecd8ae1@github.com>

On Fri, 20 Jan 2023 21:24:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - 8297814: Address reviewer comments
>  - 8297814: (fs) Re-visit Path.getExtension return value

This PR to be superseded by the work for https://bugs.openjdk.org/browse/JDK-8298318.

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

PR: https://git.openjdk.org/jdk/pull/11545

From bpb at openjdk.org  Tue Feb  7 00:31:59 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 00:31:59 GMT
Subject: Withdrawn: 8297814: (fs) Re-visit Path.getExtension return value
In-Reply-To: <zMvOgJCwfHo7TDN0A_iT-NDEha0alAhOZj2LlCMQuzI=.83b43e96-fe35-4a56-896c-382ff454db4f@github.com>
References: <zMvOgJCwfHo7TDN0A_iT-NDEha0alAhOZj2LlCMQuzI=.83b43e96-fe35-4a56-896c-382ff454db4f@github.com>
Message-ID: <LDXptoh_Zhb0u0Pk6UsMufGZCvkT3luW3gkIePFRh4A=.35c4ec4f-b0de-4000-967f-c29d2abf981a@github.com>

On Tue, 6 Dec 2022 18:15:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/11545

From alanb at openjdk.org  Tue Feb  7 11:53:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 11:53:50 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v2]
In-Reply-To: <2tJTe4YyVh4scGpg-oedUPrE6hIHUUE2Dujo2kG0aYM=.bf7a3d41-7085-4481-a173-7e967d592e5b@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <2tJTe4YyVh4scGpg-oedUPrE6hIHUUE2Dujo2kG0aYM=.bf7a3d41-7085-4481-a173-7e967d592e5b@github.com>
Message-ID: <2dWkseNvNvy61pljtuP5RdKQbuNob-8i4oloe3Foa1c=.2880e442-ab94-4c7f-94d4-efce5e8db6a4@github.com>

On Tue, 7 Feb 2023 00:23:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298478: Verify parsed type is acceptable for prefix type; add some cases to test

src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 36:

> 34: class WindowsPathParser {
> 35:     private static final String LONG_PATH_PREFIX     = "\\\\?\\";
> 36:     private static final String LONG_PATH_UNC_PREFIX = LONG_PATH_PREFIX + "UNC";

Shouldn't this be "\?\UNC" ?

src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 111:

> 109:             input = input.substring(4);
> 110:         } else {
> 111:             prefixType = PREFIX_TYPE_NONE;

This looks okay but it means 2 x startsWith tests for the common case. If the input doesn't start with LONG_PATH_PREFIX then there is no need to check if starts with the UNC version.

Another idea here is drop the PREFIX_TYPE_xxx fields and just have an expectedType field of type WindowsPathType.

src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 172:

> 170:             throw new InvalidPathException(input, "Long path prefix must precede an absolute path");
> 171:         } else if (prefixType == PREFIX_TYPE_LONG_UNC && type != WindowsPathType.UNC) {
> 172:             throw new InvalidPathException(input, "Long UNC path prefix must precede a UNC path");

I don't think the text should have "must precede" as someone reading this might assume they must use this prefix. Maybe say "cannot be used with ..." ?

test/jdk/java/nio/file/Path/PathOps.java line 1458:

> 1456:         test("\\\\?\\UNC\\server\\share\\dir\\file.dat")      // UNC
> 1457:             .string("\\\\server\\share\\dir\\file.dat");
> 1458:         test("\\\\?\\UNC\\server\\share\\C:\\mnt\\file.dat")  // absolute

Shouldn't this be "\\\?\\UNC\\C:\\file.dat"?

Also can we try a relative path, e.g.  "\\\?\\UNC\\file.dat"

test/jdk/java/nio/file/Path/PathOps.java line 1462:

> 1460:         test("\\\\?\\UNC\\server\\share\\C:file.dat")         // drive-relative
> 1461:             .invalid();
> 1462:         test("\\\\?\\UNC")                                    // empty

Probably want "\\\?\\UNC\") too.

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

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 18:02:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 18:02:55 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v3]
In-Reply-To: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
Message-ID: <_FVnBFowYXugcM50uvy69IF4XdIcukaCnJk2dqQG0e0=.77e068c3-b69d-4abb-8b18-e21b6f887195@github.com>

> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8298478: Address reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12423/files
  - new: https://git.openjdk.org/jdk/pull/12423/files/89d757f4..90ef2d30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12423&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12423&range=01-02

  Stats: 29 lines in 2 files changed: 8 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12423.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12423/head:pull/12423

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 18:03:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 18:03:03 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v2]
In-Reply-To: <2dWkseNvNvy61pljtuP5RdKQbuNob-8i4oloe3Foa1c=.2880e442-ab94-4c7f-94d4-efce5e8db6a4@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <2tJTe4YyVh4scGpg-oedUPrE6hIHUUE2Dujo2kG0aYM=.bf7a3d41-7085-4481-a173-7e967d592e5b@github.com>
 <2dWkseNvNvy61pljtuP5RdKQbuNob-8i4oloe3Foa1c=.2880e442-ab94-4c7f-94d4-efce5e8db6a4@github.com>
Message-ID: <JcaaA4b0vas3-0TLo86FlaG0ErelAMH18TgnGSn6Z9U=.5f32e145-ea06-4eed-bbaf-ed9c587a2057@github.com>

On Tue, 7 Feb 2023 11:49:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8298478: Verify parsed type is acceptable for prefix type; add some cases to test
>
> src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 36:
> 
>> 34: class WindowsPathParser {
>> 35:     private static final String LONG_PATH_PREFIX     = "\\\\?\\";
>> 36:     private static final String LONG_PATH_UNC_PREFIX = LONG_PATH_PREFIX + "UNC";
> 
> Shouldn't this be "\\\?\\UNC\" ?

Yes. Fixed in 90ef2d30a9ed8f7ddb5891836663e5f8728a948d.

> src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 111:
> 
>> 109:             input = input.substring(4);
>> 110:         } else {
>> 111:             prefixType = PREFIX_TYPE_NONE;
> 
> This looks okay but it means 2 x startsWith tests for the common case. If the input doesn't start with LONG_PATH_PREFIX then there is no need to check if starts with the UNC version.
> 
> Another idea here is drop the PREFIX_TYPE_xxx fields and just have an expectedType field of type WindowsPathType.

Fixed in 90ef2d30a9ed8f7ddb5891836663e5f8728a948d.

> test/jdk/java/nio/file/Path/PathOps.java line 1458:
> 
>> 1456:         test("\\\\?\\UNC\\server\\share\\dir\\file.dat")      // UNC
>> 1457:             .string("\\\\server\\share\\dir\\file.dat");
>> 1458:         test("\\\\?\\UNC\\server\\share\\C:\\mnt\\file.dat")  // absolute
> 
> Shouldn't this be "\\\?\\UNC\\C:\\file.dat"?
> 
> Also can we try a relative path, e.g.  "\\\?\\UNC\\file.dat"

Updated and amended in 90ef2d30a9ed8f7ddb5891836663e5f8728a948d.

> test/jdk/java/nio/file/Path/PathOps.java line 1462:
> 
>> 1460:         test("\\\\?\\UNC\\server\\share\\C:file.dat")         // drive-relative
>> 1461:             .invalid();
>> 1462:         test("\\\\?\\UNC")                                    // empty
> 
> Probably want "\\\?\\UNC\") too.

So changed in 90ef2d30a9ed8f7ddb5891836663e5f8728a948d.

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

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 18:22:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 18:22:58 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v3]
In-Reply-To: <_FVnBFowYXugcM50uvy69IF4XdIcukaCnJk2dqQG0e0=.77e068c3-b69d-4abb-8b18-e21b6f887195@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <_FVnBFowYXugcM50uvy69IF4XdIcukaCnJk2dqQG0e0=.77e068c3-b69d-4abb-8b18-e21b6f887195@github.com>
Message-ID: <MtMgimpOHmmCmJwmAPAXuIlLk7mznpy3OUylbRsrb1w=.8b4e0780-6b03-454f-868e-807984a47923@github.com>

On Tue, 7 Feb 2023 18:02:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298478: Address reviewer comments

src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 164:

> 162:         }
> 163: 
> 164:         if (type != expectedType) {

Maybe this should also have `expectedType != null` either before of after the existing check?

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

PR: https://git.openjdk.org/jdk/pull/12423

From alanb at openjdk.org  Tue Feb  7 18:45:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 18:45:26 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v3]
In-Reply-To: <MtMgimpOHmmCmJwmAPAXuIlLk7mznpy3OUylbRsrb1w=.8b4e0780-6b03-454f-868e-807984a47923@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <_FVnBFowYXugcM50uvy69IF4XdIcukaCnJk2dqQG0e0=.77e068c3-b69d-4abb-8b18-e21b6f887195@github.com>
 <MtMgimpOHmmCmJwmAPAXuIlLk7mznpy3OUylbRsrb1w=.8b4e0780-6b03-454f-868e-807984a47923@github.com>
Message-ID: <DtyeuFU0teOQG6yiMNSY2FV_A5hXRfmIIQqGbYHg3xg=.6f7e1867-65f6-423f-ba53-be1501b1bc87@github.com>

On Tue, 7 Feb 2023 18:20:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8298478: Address reviewer comments
>
> src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 164:
> 
>> 162:         }
>> 163: 
>> 164:         if (type != expectedType) {
> 
> Maybe this should also have `expectedType != null` either before of after the existing check?

Yes, `if (expectedType != null && type != expectedType)` would be clearer.

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

PR: https://git.openjdk.org/jdk/pull/12423

From alanb at openjdk.org  Tue Feb  7 18:45:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 18:45:30 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v3]
In-Reply-To: <_FVnBFowYXugcM50uvy69IF4XdIcukaCnJk2dqQG0e0=.77e068c3-b69d-4abb-8b18-e21b6f887195@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <_FVnBFowYXugcM50uvy69IF4XdIcukaCnJk2dqQG0e0=.77e068c3-b69d-4abb-8b18-e21b6f887195@github.com>
Message-ID: <YmNafmP1yznUFhckAOhNsx9zERh9h62SiTAYBkuwvOk=.8901c040-7820-4942-8b11-d52cff059704@github.com>

On Tue, 7 Feb 2023 18:02:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298478: Address reviewer comments

test/jdk/java/nio/file/Path/PathOps.java line 1466:

> 1464:         test("\\\\?\\UNC")                                    // empty
> 1465:             .invalid();
> 1466:         test("\\\\?\\UNC\\")                                    // empty

The comment on this line isn't aligned with the other but the updated list of test cases looks good/complete.

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

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 19:19:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 19:19:03 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v4]
In-Reply-To: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
Message-ID: <BfPGci-VahMPk1sYvUuiVdzSo9qd9x38dpHDp09M1y8=.8a456dfc-86c9-4a0e-8d32-5c3c603983de@github.com>

> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8298478: Improve conditional; align comment in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12423/files
  - new: https://git.openjdk.org/jdk/pull/12423/files/90ef2d30..f9de5966

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12423&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12423&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12423.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12423/head:pull/12423

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 19:19:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 19:19:07 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v3]
In-Reply-To: <DtyeuFU0teOQG6yiMNSY2FV_A5hXRfmIIQqGbYHg3xg=.6f7e1867-65f6-423f-ba53-be1501b1bc87@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <_FVnBFowYXugcM50uvy69IF4XdIcukaCnJk2dqQG0e0=.77e068c3-b69d-4abb-8b18-e21b6f887195@github.com>
 <MtMgimpOHmmCmJwmAPAXuIlLk7mznpy3OUylbRsrb1w=.8b4e0780-6b03-454f-868e-807984a47923@github.com>
 <DtyeuFU0teOQG6yiMNSY2FV_A5hXRfmIIQqGbYHg3xg=.6f7e1867-65f6-423f-ba53-be1501b1bc87@github.com>
Message-ID: <JsZY3-VmRrXEWNQ1srG2JFsX12WTvKYMr9bqpxapUKk=.dee99a3f-bc84-4d37-9d91-6ed38350f781@github.com>

On Tue, 7 Feb 2023 18:41:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 164:
>> 
>>> 162:         }
>>> 163: 
>>> 164:         if (type != expectedType) {
>> 
>> Maybe this should also have `expectedType != null` either before of after the existing check?
>
> Yes, `if (expectedType != null && type != expectedType)` would be clearer.

So changed in f9de5966fe505249fb373bcd8551183977e5e8e3.

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

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 19:19:11 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 19:19:11 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v2]
In-Reply-To: <2dWkseNvNvy61pljtuP5RdKQbuNob-8i4oloe3Foa1c=.2880e442-ab94-4c7f-94d4-efce5e8db6a4@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <2tJTe4YyVh4scGpg-oedUPrE6hIHUUE2Dujo2kG0aYM=.bf7a3d41-7085-4481-a173-7e967d592e5b@github.com>
 <2dWkseNvNvy61pljtuP5RdKQbuNob-8i4oloe3Foa1c=.2880e442-ab94-4c7f-94d4-efce5e8db6a4@github.com>
Message-ID: <EYKSSrXuWvfYA1LlJ1QhMMH2uYL3Sx1PmS2miD3n8ck=.c4809831-82ad-4603-b30a-b96f223faea2@github.com>

On Tue, 7 Feb 2023 11:44:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8298478: Verify parsed type is acceptable for prefix type; add some cases to test
>
> src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java line 172:
> 
>> 170:             throw new InvalidPathException(input, "Long path prefix must precede an absolute path");
>> 171:         } else if (prefixType == PREFIX_TYPE_LONG_UNC && type != WindowsPathType.UNC) {
>> 172:             throw new InvalidPathException(input, "Long UNC path prefix must precede a UNC path");
> 
> I don't think the text should have "must precede" as someone reading this might assume they must use this prefix. Maybe say "cannot be used with ..." ?

Fixed in 90ef2d30a9ed8f7ddb5891836663e5f8728a948d.

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

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Tue Feb  7 19:19:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 19:19:13 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v3]
In-Reply-To: <YmNafmP1yznUFhckAOhNsx9zERh9h62SiTAYBkuwvOk=.8901c040-7820-4942-8b11-d52cff059704@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <_FVnBFowYXugcM50uvy69IF4XdIcukaCnJk2dqQG0e0=.77e068c3-b69d-4abb-8b18-e21b6f887195@github.com>
 <YmNafmP1yznUFhckAOhNsx9zERh9h62SiTAYBkuwvOk=.8901c040-7820-4942-8b11-d52cff059704@github.com>
Message-ID: <M27PcTYO9QGdWr1at3HbkAoX2W8AtnLSKRTN98q_gL8=.96edb2b5-7a86-49b7-bb1e-d1318cecb945@github.com>

On Tue, 7 Feb 2023 18:42:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8298478: Address reviewer comments
>
> test/jdk/java/nio/file/Path/PathOps.java line 1466:
> 
>> 1464:         test("\\\\?\\UNC")                                    // empty
>> 1465:             .invalid();
>> 1466:         test("\\\\?\\UNC\\")                                    // empty
> 
> The comment on this line isn't aligned with the other but the updated list of test cases looks good/complete.

Aligned in f9de5966fe505249fb373bcd8551183977e5e8e3.

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

PR: https://git.openjdk.org/jdk/pull/12423

From alanb at openjdk.org  Tue Feb  7 20:15:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 20:15:38 GMT
Subject: RFR: 8298478: (fs) Path.of should allow input to include long path
 prefix [v4]
In-Reply-To: <BfPGci-VahMPk1sYvUuiVdzSo9qd9x38dpHDp09M1y8=.8a456dfc-86c9-4a0e-8d32-5c3c603983de@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
 <BfPGci-VahMPk1sYvUuiVdzSo9qd9x38dpHDp09M1y8=.8a456dfc-86c9-4a0e-8d32-5c3c603983de@github.com>
Message-ID: <SxdEpmlMZsxCwlcwYKJeHZynf6nLQ8wIbRj1gCvN2vc=.e03d8b34-c9d6-405e-9c59-6447c23257b1@github.com>

On Tue, 7 Feb 2023 19:19:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298478: Improve conditional; align comment in test

Latest version addresses all my comments.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Wed Feb  8 19:23:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 8 Feb 2023 19:23:55 GMT
Subject: Integrated: 8298478: (fs) Path.of should allow input to include long
 path prefix
In-Reply-To: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
References: <V0bzRf5cxDGGWFxXoYzJ5H_2SoYBqzg4ajB5gNebUoQ=.8e72d184-0e66-48f6-adf3-9108bb201d80@github.com>
Message-ID: <YAeM7mVn0y0wG-DArO7Seg79ht8WltgI9qOlDBGxeMw=.fec8528b-322b-4dab-84b7-6f8012b36281@github.com>

On Sat, 4 Feb 2023 00:03:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the long path `\?` or `\?\UNC` prefix before creating the `WindowsPath` instance..

This pull request has now been integrated.

Changeset: 638d612c
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/638d612c6b7c08c1f7be0d4e75e9f8a6dca1ef19
Stats:     53 lines in 2 files changed: 50 ins; 0 del; 3 mod

8298478: (fs) Path.of should allow input to include long path prefix

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/12423

From bpb at openjdk.org  Wed Feb  8 21:56:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 8 Feb 2023 21:56:36 GMT
Subject: RFR: 7174305: (ch) Channels.newReader doesn't throw
 IllegalBlockingModeException if channel is configured non-blocking
Message-ID: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>

Modify `sun.nio.cs.StreamDecoder::readBytes` to throw `IllegalBlockingModeException` if its channel is configured to be non-blocking.

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

Commit messages:
 - 7174305: (ch) Channels.newReader doesn't throw IllegalBlockingMode if channel is configured non-blocking

Changes: https://git.openjdk.org/jdk/pull/12478/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7174305
  Stats: 91 lines in 2 files changed: 83 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12478.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12478/head:pull/12478

PR: https://git.openjdk.org/jdk/pull/12478

From bpb at openjdk.org  Thu Feb  9 02:15:35 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 9 Feb 2023 02:15:35 GMT
Subject: RFR: 8297292: java/nio/channels/FileChannel/FileExtensionAndMap.java
 is too slow
Message-ID: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>

Reduce the test?s disk space requirement by one third and the total number of files tested by half. With this change, the test was observed to still fail with a SIGBUS using JDK 11.0.15 on Linux 5.15.0-58. The test?s run time decreased by about two thirds: for one sample run from 29m56s to 10m13s in the CI on Linux-x64. A run with 50 repeats had no failures.

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

Commit messages:
 - 8297292: java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow

Changes: https://git.openjdk.org/jdk/pull/12479/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297292
  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12479.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12479/head:pull/12479

PR: https://git.openjdk.org/jdk/pull/12479

From jpai at openjdk.org  Thu Feb  9 06:03:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 9 Feb 2023 06:03:50 GMT
Subject: RFR: 8297292:
 java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow
In-Reply-To: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
References: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
Message-ID: <SGresp2wUdeziiqC1IxxPTxzOw8j5Pe_4PFO0je_EyA=.8401655c-76c4-4d86-95f8-1867f125747b@github.com>

On Thu, 9 Feb 2023 02:08:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Reduce the test?s disk space requirement by one third and the total number of files tested by half. With this change, the test was observed to still fail with a SIGBUS using JDK 11.0.15 on Linux 5.15.0-58. The test?s run time decreased by about two thirds: for one sample run from 29m56s to 10m13s in the CI on Linux-x64. A run with 50 repeats had no failures.

Hello Brian, the change looks fine to me. FileExtensionAndMap.java will need a copyright year update before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12479

From alanb at openjdk.org  Thu Feb  9 07:00:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Feb 2023 07:00:42 GMT
Subject: RFR: 8297292:
 java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow
In-Reply-To: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
References: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
Message-ID: <U33EkYrLoO7FclgN0IEDnvzkTegwIUs2RbeBPxZA7FM=.6f735828-aa60-4c4c-ac42-9d02de943071@github.com>

On Thu, 9 Feb 2023 02:08:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Reduce the test?s disk space requirement by one third and the total number of files tested by half. With this change, the test was observed to still fail with a SIGBUS using JDK 11.0.15 on Linux 5.15.0-58. The test?s run time decreased by about two thirds: for one sample run from 29m56s to 10m13s in the CI on Linux-x64. A run with 50 repeats had no failures.

10mins is still very slow for a test in this area, I wonder if there is a better way to test this scenario that would run in a much short time.

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

PR: https://git.openjdk.org/jdk/pull/12479

From alanb at openjdk.org  Thu Feb  9 07:21:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Feb 2023 07:21:44 GMT
Subject: RFR: 7174305: (ch) Channels.newReader doesn't throw
 IllegalBlockingModeException if channel is configured non-blocking
In-Reply-To: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>
References: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>
Message-ID: <SdPUUbJ6BwEuJnxmsfgoXs2q2nc2CRgs2kXLhbYKUxI=.6a6ff8a8-095d-41eb-a18e-25c7fdb0d5ba@github.com>

On Wed, 8 Feb 2023 21:48:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `sun.nio.cs.StreamDecoder::readBytes` to throw `IllegalBlockingModeException` if its channel is configured to be non-blocking.

I think we'll need to hold off on this one until Java monitors have been re-implemented.

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

PR: https://git.openjdk.org/jdk/pull/12478

From bpb at openjdk.org  Thu Feb  9 15:29:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 9 Feb 2023 15:29:03 GMT
Subject: RFR: 7174305: (ch) Channels.newReader doesn't throw
 IllegalBlockingModeException if channel is configured non-blocking [v2]
In-Reply-To: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>
References: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>
Message-ID: <y6yosQDt1ON75Cnx_p0Hhw43bEta6ovoiHEzMLEJEoE=.321e2e6f-339b-4f0d-a741-89d4b746b591@github.com>

> Modify `sun.nio.cs.StreamDecoder::readBytes` to throw `IllegalBlockingModeException` if its channel is configured to be non-blocking.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  7174305: Catch expected IllegalBlockingMode in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12478/files
  - new: https://git.openjdk.org/jdk/pull/12478/files/651e5929..ab318551

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12478&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12478&range=00-01

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12478.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12478/head:pull/12478

PR: https://git.openjdk.org/jdk/pull/12478

From mkartashev at openjdk.org  Thu Feb  9 15:40:54 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 9 Feb 2023 15:40:54 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <4218710C-D702-4F94-A172-18AE41977215@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <4218710C-D702-4F94-A172-18AE41977215@gmail.com>
Message-ID: <eLWruYpLk6UelkXy37mtzrjOlIgeQ3UBiDhsd7pgdy0=.f1e284ba-a087-447d-9fcf-277828e1cbab@github.com>

On Sat, 4 Feb 2023 11:37:39 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> How will your changes be tested if the PR has been closed?

I guess I'll re-open it, perhaps as a new one if necessary. As you correctly noted, I can't test this fully by myself so I have to make the code available to others somehow.

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

PR: https://git.openjdk.org/jdk/pull/10140

From bpb at openjdk.org  Thu Feb  9 16:10:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 9 Feb 2023 16:10:45 GMT
Subject: RFR: 7174305: (ch) Channels.newReader doesn't throw
 IllegalBlockingModeException if channel is configured non-blocking
In-Reply-To: <SdPUUbJ6BwEuJnxmsfgoXs2q2nc2CRgs2kXLhbYKUxI=.6a6ff8a8-095d-41eb-a18e-25c7fdb0d5ba@github.com>
References: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>
 <SdPUUbJ6BwEuJnxmsfgoXs2q2nc2CRgs2kXLhbYKUxI=.6a6ff8a8-095d-41eb-a18e-25c7fdb0d5ba@github.com>
Message-ID: <-GTyco99MNX_g8b1w2ZLu2e2ulnRNNqeOmF-6pLF17Y=.8f135d27-6eb5-4082-a78c-c559652060b5@github.com>

On Thu, 9 Feb 2023 07:18:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we'll need to hold off on this one until Java monitors have been re-implemented.

Is there an issue on file for that?

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

PR: https://git.openjdk.org/jdk/pull/12478

From bpb at openjdk.org  Thu Feb  9 16:37:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 9 Feb 2023 16:37:24 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <eLWruYpLk6UelkXy37mtzrjOlIgeQ3UBiDhsd7pgdy0=.f1e284ba-a087-447d-9fcf-277828e1cbab@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <4218710C-D702-4F94-A172-18AE41977215@gmail.com>
 <eLWruYpLk6UelkXy37mtzrjOlIgeQ3UBiDhsd7pgdy0=.f1e284ba-a087-447d-9fcf-277828e1cbab@github.com>
Message-ID: <pPd01cPMWeH7DIK6uuoJxIW8Zk3VMlAP__6W0CB1xIE=.388f146b-e487-4860-8f8a-d46c970740d2@github.com>

On Thu, 9 Feb 2023 15:37:11 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> [...] I can't test this fully by myself so I have to make the code available to others somehow.

I think that we can help with testing.

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

PR: https://git.openjdk.org/jdk/pull/10140

From bpb at openjdk.org  Thu Feb  9 16:44:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 9 Feb 2023 16:44:15 GMT
Subject: RFR: 8297292:
 java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow [v2]
In-Reply-To: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
References: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
Message-ID: <x5_2z8VhMh7Vs-V4Kgh9rOoNgadX5Oc-SyWxEsoUAA4=.3d3eef8c-d017-4f8e-b690-bbc66e2dd934@github.com>

> Reduce the test?s disk space requirement by one third and the total number of files tested by half. With this change, the test was observed to still fail with a SIGBUS using JDK 11.0.15 on Linux 5.15.0-58. The test?s run time decreased by about two thirds: for one sample run from 29m56s to 10m13s in the CI on Linux-x64. A run with 50 repeats had no failures.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8297292: Increment copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12479/files
  - new: https://git.openjdk.org/jdk/pull/12479/files/31d5700b..0be05b22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12479&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12479&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12479.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12479/head:pull/12479

PR: https://git.openjdk.org/jdk/pull/12479

From bpb at openjdk.org  Fri Feb 10 16:58:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 16:58:43 GMT
Subject: RFR: 8297292:
 java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow [v2]
In-Reply-To: <x5_2z8VhMh7Vs-V4Kgh9rOoNgadX5Oc-SyWxEsoUAA4=.3d3eef8c-d017-4f8e-b690-bbc66e2dd934@github.com>
References: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
 <x5_2z8VhMh7Vs-V4Kgh9rOoNgadX5Oc-SyWxEsoUAA4=.3d3eef8c-d017-4f8e-b690-bbc66e2dd934@github.com>
Message-ID: <9uwnK8qTJS-X3zUOtx43tbXXEe1RLsMULLtt2n2P-hU=.7abe230b-5841-4ee7-8f7a-3fa2d9a5f827@github.com>

On Thu, 9 Feb 2023 16:44:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Reduce the test?s disk space requirement by one third and the total number of files tested by half. With this change, the test was observed to still fail with a SIGBUS using JDK 11.0.15 on Linux 5.15.0-58. The test?s run time decreased by about two thirds: for one sample run from 29m56s to 10m13s in the CI on Linux-x64. A run with 50 repeats had no failures.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297292: Increment copyright year

`FileExtensionAndMap.java` was added by the change which resolved [JDK-8168628](https://bugs.openjdk.org/browse/JDK-8168628). That change was backed out of JDK 11 because it broke sparse files. The underlying issue was really `Unsafe::copy[Swap]Memory` not using memory guards which was tracked in [JDK-8191278](https://bugs.openjdk.org/browse/JDK-8191278). The fix for this latter issue added the test `test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java` which is presumably sufficient to test for the underlying cause for which `FileExtensionAndMap.java` is also testing. Given this quasi duplication, it appears safe to simply remove `FileExtensionAndMap.java` altogether.

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

PR: https://git.openjdk.org/jdk/pull/12479

From bpb at openjdk.org  Fri Feb 10 17:08:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 17:08:36 GMT
Subject: RFR: 8297292:
 java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow [v3]
In-Reply-To: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
References: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
Message-ID: <hCMDjTQCNoF6AJtCokdhr62JQEkCwjE9CaNwwVXK_Es=.ea3107ac-deb3-4ed6-b0e9-b290fb782a4a@github.com>

> Reduce the test?s disk space requirement by one third and the total number of files tested by half. With this change, the test was observed to still fail with a SIGBUS using JDK 11.0.15 on Linux 5.15.0-58. The test?s run time decreased by about two thirds: for one sample run from 29m56s to 10m13s in the CI on Linux-x64. A run with 50 repeats had no failures.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8297292: Remove FileExtensionAndMap test as the failure is covered by InternalErrorTest.java for Unsafe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12479/files
  - new: https://git.openjdk.org/jdk/pull/12479/files/0be05b22..44bc728a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12479&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12479&range=01-02

  Stats: 239 lines in 1 file changed: 0 ins; 239 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12479.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12479/head:pull/12479

PR: https://git.openjdk.org/jdk/pull/12479

From alanb at openjdk.org  Fri Feb 10 17:12:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 17:12:23 GMT
Subject: RFR: 8297292:
 java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow [v3]
In-Reply-To: <hCMDjTQCNoF6AJtCokdhr62JQEkCwjE9CaNwwVXK_Es=.ea3107ac-deb3-4ed6-b0e9-b290fb782a4a@github.com>
References: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
 <hCMDjTQCNoF6AJtCokdhr62JQEkCwjE9CaNwwVXK_Es=.ea3107ac-deb3-4ed6-b0e9-b290fb782a4a@github.com>
Message-ID: <fni99rju-MRIXM7uaOe1LL1nMWkPZRsrZzDyrtss83c=.63b96ae1-1296-4279-acd1-b6c6581a8410@github.com>

On Fri, 10 Feb 2023 17:08:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Reduce the test?s disk space requirement by one third and the total number of files tested by half. With this change, the test was observed to still fail with a SIGBUS using JDK 11.0.15 on Linux 5.15.0-58. The test?s run time decreased by about two thirds: for one sample run from 29m56s to 10m13s in the CI on Linux-x64. A run with 50 repeats had no failures.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297292: Remove FileExtensionAndMap test as the failure is covered by InternalErrorTest.java for Unsafe

The deletion looks fine.

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

PR: https://git.openjdk.org/jdk/pull/12479

From bpb at openjdk.org  Fri Feb 10 17:46:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 17:46:54 GMT
Subject: RFR: 7174305: (ch) Channels.newReader doesn't throw
 IllegalBlockingModeException if channel is configured non-blocking [v2]
In-Reply-To: <y6yosQDt1ON75Cnx_p0Hhw43bEta6ovoiHEzMLEJEoE=.321e2e6f-339b-4f0d-a741-89d4b746b591@github.com>
References: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>
 <y6yosQDt1ON75Cnx_p0Hhw43bEta6ovoiHEzMLEJEoE=.321e2e6f-339b-4f0d-a741-89d4b746b591@github.com>
Message-ID: <y-_BlBgUYUjLXpAoYb-bqrPTr_wKcVa34wZpXhiP9pw=.510cb866-a07c-4a5a-a58a-867c38428566@github.com>

On Thu, 9 Feb 2023 15:29:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.nio.cs.StreamDecoder::readBytes` to throw `IllegalBlockingModeException` if its channel is configured to be non-blocking.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7174305: Catch expected IllegalBlockingMode in test

Closing this PR until better monitors are available.

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

PR: https://git.openjdk.org/jdk/pull/12478

From bpb at openjdk.org  Fri Feb 10 17:46:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 17:46:56 GMT
Subject: Withdrawn: 7174305: (ch) Channels.newReader doesn't throw
 IllegalBlockingModeException if channel is configured non-blocking
In-Reply-To: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>
References: <wXv6xrlIqz27c_r78YJrn3u5ybMEoLd_3J7I0Jsz2nU=.453bc85a-4270-49c6-b0ca-2d09cd36dbff@github.com>
Message-ID: <DgZNIffi8H_U3M3l_CLsLZND1fgwaMJGqqfrFhbHu3Q=.2841037e-4c14-450e-9aed-fda7cdb69a9f@github.com>

On Wed, 8 Feb 2023 21:48:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `sun.nio.cs.StreamDecoder::readBytes` to throw `IllegalBlockingModeException` if its channel is configured to be non-blocking.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12478

From bpb at openjdk.org  Fri Feb 10 19:46:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 19:46:54 GMT
Subject: Integrated: 8297292:
 java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow
In-Reply-To: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
References: <ZjW1kb2ygPjBH0DHzKNpGxj1L626BXPhHJcVc_hY0a8=.aa871e16-2965-4ff9-aa83-16ee16dff017@github.com>
Message-ID: <d4bGrg2FRKuVcv2Hetj1ralaTBibjSl9PhyrvOGwg6U=.56dadcca-2cd2-4199-a3e2-8a885c0033c4@github.com>

On Thu, 9 Feb 2023 02:08:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Reduce the test?s disk space requirement by one third and the total number of files tested by half. With this change, the test was observed to still fail with a SIGBUS using JDK 11.0.15 on Linux 5.15.0-58. The test?s run time decreased by about two thirds: for one sample run from 29m56s to 10m13s in the CI on Linux-x64. A run with 50 repeats had no failures.

This pull request has now been integrated.

Changeset: 84e47996
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84e47996e88cf640e5e9d5ab4be8a640c67afbf5
Stats:     240 lines in 2 files changed: 0 ins; 240 del; 0 mod

8297292: java/nio/channels/FileChannel/FileExtensionAndMap.java is too slow

Reviewed-by: jpai

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

PR: https://git.openjdk.org/jdk/pull/12479

From bhuang at openjdk.org  Wed Feb 15 20:31:53 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 15 Feb 2023 20:31:53 GMT
Subject: RFR: JDK-8300912: Update java/nio/MappedByteBuffer/PmemTest.java
 to run on x86_64 only [v2]
In-Reply-To: <iCsNXiV_PMMic10mqC5Yx0Xw4nJl5mOKxb-37QrR03E=.1542ef36-70af-43c8-ae1b-9a99eaf2a5da@github.com>
References: <iCsNXiV_PMMic10mqC5Yx0Xw4nJl5mOKxb-37QrR03E=.1542ef36-70af-43c8-ae1b-9a99eaf2a5da@github.com>
Message-ID: <EHP5RGBBkpy3oUuVrisMDDuPyDr7CxfUTKNnHWJTpfU=.23345e6a-2b59-41fd-a7f1-c29bab485d7e@github.com>

> This task is created to update jtreg test to run on x86 only because pmem emulation is only supported on x86. For other architectures with external NVRAM, run test with java PmemTest.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Moved the aarch64 to a new test instance.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12352/files
  - new: https://git.openjdk.org/jdk/pull/12352/files/cd941791..bcbb7389

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12352&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12352&range=00-01

  Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12352.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12352/head:pull/12352

PR: https://git.openjdk.org/jdk/pull/12352

From duke at openjdk.org  Wed Feb 15 21:09:45 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 15 Feb 2023 21:09:45 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset
Message-ID: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>

A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.

The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.

I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.

In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.

I need someone to help me open an Issue on JBS. Thank you very much.

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

Commit messages:
 - Use Set.of in Charset

Changes: https://git.openjdk.org/jdk/pull/12570/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302603
  Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12570.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12570/head:pull/12570

PR: https://git.openjdk.org/jdk/pull/12570

From naoto at openjdk.org  Wed Feb 15 21:09:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Feb 2023 21:09:46 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset
In-Reply-To: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
Message-ID: <-VsyWuvNrYCcyfF3zyuzSCVybPF4IL8z79z771fAsPw=.3d42df7d-aef8-49aa-99ca-49e0b0e796e1@github.com>

On Wed, 15 Feb 2023 09:42:53 GMT, Glavo <duke at openjdk.org> wrote:

> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
> 
> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
> 
> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
> 
> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
> 
> I need someone to help me open an Issue on JBS. Thank you very much.

Good cleanup. Filed an issue: https://bugs.openjdk.org/browse/JDK-8302603

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

PR: https://git.openjdk.org/jdk/pull/12570

From duke at openjdk.org  Wed Feb 15 21:09:46 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 15 Feb 2023 21:09:46 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset
In-Reply-To: <-VsyWuvNrYCcyfF3zyuzSCVybPF4IL8z79z771fAsPw=.3d42df7d-aef8-49aa-99ca-49e0b0e796e1@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
 <-VsyWuvNrYCcyfF3zyuzSCVybPF4IL8z79z771fAsPw=.3d42df7d-aef8-49aa-99ca-49e0b0e796e1@github.com>
Message-ID: <iJ3qbzRLuLYy0ly31WHQ8M5eo2hEPlBYyRdFFFQ-Lrc=.b7161869-411b-425a-8971-ed6d0c9b99ac@github.com>

On Wed, 15 Feb 2023 19:25:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Good cleanup. Filed an issue: https://bugs.openjdk.org/browse/JDK-8302603

Thank you!

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

PR: https://git.openjdk.org/jdk/pull/12570

From mik3hall at gmail.com  Wed Feb 15 23:36:14 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 15 Feb 2023 17:36:14 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <eLWruYpLk6UelkXy37mtzrjOlIgeQ3UBiDhsd7pgdy0=.f1e284ba-a087-447d-9fcf-277828e1cbab@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <4218710C-D702-4F94-A172-18AE41977215@gmail.com>
 <eLWruYpLk6UelkXy37mtzrjOlIgeQ3UBiDhsd7pgdy0=.f1e284ba-a087-447d-9fcf-277828e1cbab@github.com>
Message-ID: <C7DE7A44-3474-4E71-B35E-5BB8AA8FFB7D@gmail.com>



> On Feb 9, 2023, at 9:40 AM, Maxim Kartashev <mkartashev at openjdk.org> wrote:
> 
> On Sat, 4 Feb 2023 11:37:39 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> How will your changes be tested if the PR has been closed?
> 
> I guess I'll re-open it, perhaps as a new one if necessary. As you correctly noted, I can't test this fully by myself so I have to make the code available to others somehow.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10140

I decided to try and do a standalone version along with my OS/X default FileSystemProvider project.

Just finished throwing something together for that. 

I based it on the JetBrains runtime since the ownership status here seems still sort of undetermined. 

If this isn?t the place to discuss this let me know. If that is the case, would you be interested at all in discussing it off-list @Maxim?

My first real test with no debugging is getting?

Exception in thread "FileSystemWatcher" Exception in thread "FileSystemWatcher" java.lang.InternalError: platform encoding not initialized
	at us.hall.trz.osx.MacOSXWatchService.CFRunLoopRun(Native Method)
	at us.hall.trz.osx.MacOSXWatchService$CFRunLoopThread.run(MacOSXWatchService.java:201)

Googling the error turns up occurrences but nothing I?m really understanding as connecting to what I?m doing.

Any thoughts on this?


From stsypanov at openjdk.org  Thu Feb 16 08:07:30 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 16 Feb 2023 08:07:30 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset
In-Reply-To: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
Message-ID: <pqhKJoeuPmsj-DKo2l1kCj-JvE_3bR6V-Ug88ZUOqg4=.548d13d7-92c0-422b-aa36-6da6da9e52ea@github.com>

On Wed, 15 Feb 2023 09:42:53 GMT, Glavo <duke at openjdk.org> wrote:

> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
> 
> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
> 
> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
> 
> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
> 
> I need someone to help me open an Issue on JBS. Thank you very much.

LGTM

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

Marked as reviewed by stsypanov (Author).

PR: https://git.openjdk.org/jdk/pull/12570

From alanb at openjdk.org  Thu Feb 16 08:07:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Feb 2023 08:07:31 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset
In-Reply-To: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
Message-ID: <CS_tSKalwaZ5HvqjNlPoHKMs5z5oeRMyJLjCT9ZWlkM=.c5f68483-d2be-498a-89b0-093644944168@github.com>

On Wed, 15 Feb 2023 09:42:53 GMT, Glavo <duke at openjdk.org> wrote:

> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
> 
> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
> 
> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
> 
> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
> 
> I need someone to help me open an Issue on JBS. Thank you very much.

src/java.base/share/classes/java/nio/charset/Charset.java line 717:

> 715:     public final Set<String> aliases() {
> 716:         if (aliasSet == null)
> 717:             aliasSet = Set.of(aliases);

Given that this is racy then it might be better to use a local and avoid someone reading this code puzzling over whether it can return null, e.g.

        Set<String> aliasSet = this.aliasSet;
        if (aliasSet == null) {
            this.aliasSet = aliasSet = Set.of(aliases);
        }

You can also drop explicitly initialising it null at line 670.

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

PR: https://git.openjdk.org/jdk/pull/12570

From adinn at openjdk.org  Thu Feb 16 11:57:27 2023
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 16 Feb 2023 11:57:27 GMT
Subject: RFR: JDK-8300912: Update java/nio/MappedByteBuffer/PmemTest.java
 to run on x86_64 only
In-Reply-To: <5Y-l74ZQl-HHVYlRIjGRQo7DmGxsFnzK6GovUJNIl_g=.ebf91943-3532-440d-8bbc-428393dd7eb6@github.com>
References: <iCsNXiV_PMMic10mqC5Yx0Xw4nJl5mOKxb-37QrR03E=.1542ef36-70af-43c8-ae1b-9a99eaf2a5da@github.com>
 <5Y-l74ZQl-HHVYlRIjGRQo7DmGxsFnzK6GovUJNIl_g=.ebf91943-3532-440d-8bbc-428393dd7eb6@github.com>
Message-ID: <DSWLNaHB4XbXZPKil57wwciq5bIDDR3rPN1-fl-0XDg=.c961e4d8-c461-40cf-a298-8af5855204b8@github.com>

On Tue, 31 Jan 2023 20:40:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This task is created to update jtreg test to run on x86 only because pmem emulation is only supported on x86. For other architectures with external NVRAM, run test with java PmemTest.
>
> Maybe @adinn could comment on this as I thought this test was meant for both x64 and aarch64.

@AlanBateman Thanks for reviewing this and apologies for my late response -- I am still catching up after time lost to an injury.

The need to have a properly configured NVRAM device or pseudo-device explains why this test was written to be run manually, hence was not included in any of the normal test tiers/suites. With the appropriate environment configuration it should succeed on x86, aarch64 and ppc64(le). I am happy with the revision added by Bill.

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

PR: https://git.openjdk.org/jdk/pull/12352

From mik3hall at gmail.com  Thu Feb 16 17:54:52 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 16 Feb 2023 11:54:52 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <C7DE7A44-3474-4E71-B35E-5BB8AA8FFB7D@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <4218710C-D702-4F94-A172-18AE41977215@gmail.com>
 <eLWruYpLk6UelkXy37mtzrjOlIgeQ3UBiDhsd7pgdy0=.f1e284ba-a087-447d-9fcf-277828e1cbab@github.com>
 <C7DE7A44-3474-4E71-B35E-5BB8AA8FFB7D@gmail.com>
Message-ID: <B2BE7739-9437-4739-A92F-AA0A3CB839CB@gmail.com>



> On Feb 15, 2023, at 5:36 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Exception in thread "FileSystemWatcher" Exception in thread "FileSystemWatcher" java.lang.InternalError: platform encoding not initialized

I had to add a JNI_OnLoad to resolve jvm references which seemed to work. Initializing the encoding from there also seems to work.
The code now in fact does seem to work. Not a lot of debugging required. 
I?ll try to get my GitHub project updated with maybe improved markdown.
But for me, now with mine, this seems to work just fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230216/944c8d2b/attachment.htm>

From duke at openjdk.org  Fri Feb 17 16:59:20 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 17 Feb 2023 16:59:20 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v17]
In-Reply-To: <Jh7qxHwulfAXfKht0DbUkNwjd6JHucLHxQnanqngwvQ=.c75f6016-b88c-4c4a-a296-9f28edd14327@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
 <Jh7qxHwulfAXfKht0DbUkNwjd6JHucLHxQnanqngwvQ=.c75f6016-b88c-4c4a-a296-9f28edd14327@github.com>
Message-ID: <iXUTs9909Egth2l6i-M6yiP4sSSzrRZ7cimnB8FmpWA=.3ada411e-d773-41d3-9c16-2a3c8a49b1bb@github.com>

On Mon, 12 Dec 2022 20:04:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Implementing 8278268
>>   
>>   Signed-off-by: Markus Karg <markus at headcrashing.eu>
>
> Which platform was used to generate the performance data? Also what was the source stream? Just asking as FileChannel.transferFrom uses copy_file_range for file-to-file (Linux), memory mapping for file-to-file, and a copy loop for other cases.
> 
> In any case, the changes to ChannelInputStream.transferTo does the right thing. Most of the change in the PR is the tests. I don't have time to look at those closely right now but Lance or Brian might have cycles.

@AlanBateman @LanceAndersen Kindly asking to resume this MR. Thanks! :-)

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

PR: https://git.openjdk.org/jdk/pull/6711

From bpb at openjdk.org  Fri Feb 17 17:25:35 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Feb 2023 17:25:35 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v17]
In-Reply-To: <Jh7qxHwulfAXfKht0DbUkNwjd6JHucLHxQnanqngwvQ=.c75f6016-b88c-4c4a-a296-9f28edd14327@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
 <Jh7qxHwulfAXfKht0DbUkNwjd6JHucLHxQnanqngwvQ=.c75f6016-b88c-4c4a-a296-9f28edd14327@github.com>
Message-ID: <GD3YN3TbPKN6eiYyhmAyocyTzqJu8pADY6nLHVcwwOs=.aad35984-908a-45db-bfdb-d5a9919c5af9@github.com>

On Mon, 12 Dec 2022 20:04:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Implementing 8278268
>>   
>>   Signed-off-by: Markus Karg <markus at headcrashing.eu>
>
> Which platform was used to generate the performance data? Also what was the source stream? Just asking as FileChannel.transferFrom uses copy_file_range for file-to-file (Linux), memory mapping for file-to-file, and a copy loop for other cases.
> 
> In any case, the changes to ChannelInputStream.transferTo does the right thing. Most of the change in the PR is the tests. I don't have time to look at those closely right now but Lance or Brian might have cycles.

> @AlanBateman @LanceAndersen Kindly asking to resume this MR. Thanks! :-)

It's in my queue to help out with this.

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

PR: https://git.openjdk.org/jdk/pull/6711

From cstein at openjdk.org  Fri Feb 17 20:51:19 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 17 Feb 2023 20:51:19 GMT
Subject: RFR: 8302789: (fs) File.copy should include unsupported copy option in
 exception message
Message-ID: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>

This PR also fixes the exception message for unsupported move options.

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

Commit messages:
 - (fs) File.copy should include unsupported copy option in exception message

Changes: https://git.openjdk.org/jdk/pull/12625/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12625&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302789
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12625.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12625/head:pull/12625

PR: https://git.openjdk.org/jdk/pull/12625

From bpb at openjdk.org  Fri Feb 17 21:19:25 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Feb 2023 21:19:25 GMT
Subject: RFR: 8302789: (fs) File.copy should include unsupported copy
 option in exception message
In-Reply-To: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
Message-ID: <tV6UrXFMjZiNK8qDyk4htCHTHSoXqMxkiOpHfJby_fU=.bfa5a551-c517-423e-8f51-73791d270ccf@github.com>

On Fri, 17 Feb 2023 20:42:49 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR also fixes the exception message for unsupported move options.

The same change could be made in `unix/classes/sun/nio/fs/UnixFileSystem.java`. If that change is made in this PR, then the issue should be updated to have the OS be blank or generic instead of `windows`. The copyright year of `WindowsFileCopy` needs to be updated, as would that of `UnixFileSystem` if that class is similarly changed.

Also the issue summary and this PR's name should be changed to reference `Files::copy` rather than `File::copy`.

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

PR: https://git.openjdk.org/jdk/pull/12625

From alanb at openjdk.org  Sat Feb 18 07:11:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Feb 2023 07:11:22 GMT
Subject: RFR: 8302789: (fs) File.copy should include unsupported copy
 option in exception message
In-Reply-To: <tV6UrXFMjZiNK8qDyk4htCHTHSoXqMxkiOpHfJby_fU=.bfa5a551-c517-423e-8f51-73791d270ccf@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
 <tV6UrXFMjZiNK8qDyk4htCHTHSoXqMxkiOpHfJby_fU=.bfa5a551-c517-423e-8f51-73791d270ccf@github.com>
Message-ID: <_nP_Mh46_6llonLHS9B8BuHew8iEL_eDxNvo5aflMAc=.545faa8b-7486-49f0-810f-6db4d2e817f1@github.com>

On Fri, 17 Feb 2023 21:16:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This PR also fixes the exception message for unsupported move options.
>
> Also the issue summary and this PR's name should be changed to reference `Files::copy` rather than `File::copy`.

I agree with @bplb, it would be good to do the equivalent UnixFileSystem.{fromCopyOptions,fromMoveOptions} while you are there.

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

PR: https://git.openjdk.org/jdk/pull/12625

From alanb at openjdk.org  Sat Feb 18 07:11:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Feb 2023 07:11:24 GMT
Subject: RFR: 8302789: (fs) File.copy should include unsupported copy
 option in exception message
In-Reply-To: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
Message-ID: <XRGhVKxCvohiWuFybSTLfIg2YQVrJzgD_tfL-4co8PU=.59f68593-12f2-4fc4-9a8d-695e207888a0@github.com>

On Fri, 17 Feb 2023 20:42:49 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR also fixes the exception message for unsupported move options.

src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 304:

> 302:             }
> 303:             if (option == null) throw new NullPointerException();
> 304:             throw new UnsupportedOperationException("Unsupported move option: " + option);

The parameter is a CopyOption so changing the message to "move option" might be confusion, maybe just change it to "option"?

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

PR: https://git.openjdk.org/jdk/pull/12625

From alanb at openjdk.org  Sat Feb 18 08:27:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Feb 2023 08:27:22 GMT
Subject: RFR: 8302806: (fs) Remove unused enum
 sun.nio.file.SensitivityWatchEventModifier
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <HqeqM5WV1kmfHpIQOoVTM7ip8UICuLx1h5ZjbAa7Ubc=.bdad6b87-a668-4990-816c-411048a1651e@github.com>

On Sat, 18 Feb 2023 00:11:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This enum is not used in the JDK and did not appear in external source code searches.

This API should probably have been deprecated many releases ago. It's the jdk.unsupported module so it may be possible to remove without first deprecating.

The PR is missing the implementation and test changes.

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

PR: https://git.openjdk.org/jdk/pull/12626

From tvaleev at openjdk.org  Sat Feb 18 10:58:10 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 18 Feb 2023 10:58:10 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries
Message-ID: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>

For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.

As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

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

Commit messages:
 - 8302815 Use new Math.clamp method in core libraries

Changes: https://git.openjdk.org/jdk/pull/12633/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302815
  Stats: 41 lines in 12 files changed: 0 ins; 8 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From mik3hall at gmail.com  Sat Feb 18 14:54:56 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 18 Feb 2023 08:54:56 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <B2BE7739-9437-4739-A92F-AA0A3CB839CB@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <4218710C-D702-4F94-A172-18AE41977215@gmail.com>
 <eLWruYpLk6UelkXy37mtzrjOlIgeQ3UBiDhsd7pgdy0=.f1e284ba-a087-447d-9fcf-277828e1cbab@github.com>
 <C7DE7A44-3474-4E71-B35E-5BB8AA8FFB7D@gmail.com>
 <B2BE7739-9437-4739-A92F-AA0A3CB839CB@gmail.com>
Message-ID: <4F28CA37-1E15-4D29-93BE-EECDACAF7587@gmail.com>



> On Feb 16, 2023, at 11:54 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Feb 15, 2023, at 5:36 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> Exception in thread "FileSystemWatcher" Exception in thread "FileSystemWatcher" java.lang.InternalError: platform encoding not initialized
> 
> I had to add a JNI_OnLoad to resolve jvm references which seemed to work. Initializing the encoding from there also seems to work.
> The code now in fact does seem to work. Not a lot of debugging required. 
> I?ll try to get my GitHub project updated with maybe improved markdown.
> But for me, now with mine, this seems to work just fine.

Still a little thrown together but I have updated my GitHub project for this.

https://github.com/mik3hall/trz <https://github.com/mik3hall/trz>

My original code is a custom default FileSystemProvider. It is almost all pass through except I added some OS/X specific FileAttributeView?s for file related native api's. For your code this means you are basically a plugin WatchService replacing the default platform polling one for whatever jdk you choose to use it on. No other actual changes to the platform provider are involved.
This jdk needs to include the module jdk.incubator.foreign. I used MemoryAddress to replace the use of Unsafe getInt. A possible way around this, reverting my changes, is mentioned in the README. As are other details of what I remembered needed changing to go from a runtime based implementation to a jni one. 
I also detail some of what the original code did.   

I have test now with the nio Move, Basic, and a modified extra heavy duty LotsOfEvents. It seems to work fine. Surprisingly easily. 

So, this should mean you or anyone else who wants to can try this out against any recent openjdk version.

If anyone does, I would of course be interested in hearing about it. Especially if there are any problems related to what I?ve done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230218/85dc1e6b/attachment.htm>

From mik3hall at gmail.com  Sat Feb 18 15:00:52 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 18 Feb 2023 09:00:52 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <4F28CA37-1E15-4D29-93BE-EECDACAF7587@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <4218710C-D702-4F94-A172-18AE41977215@gmail.com>
 <eLWruYpLk6UelkXy37mtzrjOlIgeQ3UBiDhsd7pgdy0=.f1e284ba-a087-447d-9fcf-277828e1cbab@github.com>
 <C7DE7A44-3474-4E71-B35E-5BB8AA8FFB7D@gmail.com>
 <B2BE7739-9437-4739-A92F-AA0A3CB839CB@gmail.com>
 <4F28CA37-1E15-4D29-93BE-EECDACAF7587@gmail.com>
Message-ID: <56F262FE-57B9-4F3D-9C24-EE2F795DD64E@gmail.com>



> On Feb 18, 2023, at 8:54 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Feb 16, 2023, at 11:54 AM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> 
>> 
>>> On Feb 15, 2023, at 5:36 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>>> 
>>> Exception in thread "FileSystemWatcher" Exception in thread "FileSystemWatcher" java.lang.InternalError: platform encoding not initialized
>> 
>> I had to add a JNI_OnLoad to resolve jvm references which seemed to work. Initializing the encoding from there also seems to work.
>> The code now in fact does seem to work. Not a lot of debugging required. 
>> I?ll try to get my GitHub project updated with maybe improved markdown.
>> But for me, now with mine, this seems to work just fine.
> 
> Still a little thrown together but I have updated my GitHub project for this.
> 
> https://github.com/mik3hall/trz <https://github.com/mik3hall/trz>
> 
> My original code is a custom default FileSystemProvider. It is almost all pass through except I added some OS/X specific FileAttributeView?s for file related native api's. For your code this means you are basically a plugin WatchService replacing the default platform polling one for whatever jdk you choose to use it on. No other actual changes to the platform provider are involved.
> This jdk needs to include the module jdk.incubator.foreign. I used MemoryAddress to replace the use of Unsafe getInt. A possible way around this, reverting my changes, is mentioned in the README. As are other details of what I remembered needed changing to go from a runtime based implementation to a jni one. 
> I also detail some of what the original code did.   
> 
> I have test now with the nio Move, Basic, and a modified extra heavy duty LotsOfEvents. It seems to work fine. Surprisingly easily. 
> 
> So, this should mean you or anyone else who wants to can try this out against any recent openjdk version.
> 
> If anyone does, I would of course be interested in hearing about it. Especially if there are any problems related to what I?ve done.

And to possibly make it a little easier for anyone who does want to try it I added a release for the first time.
This just contains the jar (non-modular), dylib, and a sample invocation.
All it takes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230218/a78237e1/attachment-0001.htm>

From tvaleev at openjdk.org  Sat Feb 18 21:40:08 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 18 Feb 2023 21:40:08 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v2]
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>

> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
> 
> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12633/files
  - new: https://git.openjdk.org/jdk/pull/12633/files/3f3618ae..be13683b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From alanb at openjdk.org  Sun Feb 19 08:57:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Feb 2023 08:57:22 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v2]
In-Reply-To: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
Message-ID: <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>

On Sat, 18 Feb 2023 21:40:08 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

Yes, the jrt file system provider is compiled --release 8 to create lib/jrt-fs.jar. That's the plumbing needed to allow IDEs/tools running on JDK 8 access the contents of a target run-time image as a file system.

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

PR: https://git.openjdk.org/jdk/pull/12633

From alanb at openjdk.org  Mon Feb 20 17:40:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Feb 2023 17:40:26 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v2]
In-Reply-To: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
Message-ID: <x4wYWxXT9oJFQpk4omqHYAS4Iodmz1xFzqP7J9jMBIk=.e747a1e9-c0a2-4de0-b75e-dd05ce3652db@github.com>

On Sat, 18 Feb 2023 21:40:08 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
>> 
>> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

I skimmed through the usages and they look okay. I didn't spot anywhere that it differs to the existing clamping. This is the first update in 2023 for some of these files so I assume you'll bump the copyright year before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12633

From duke at openjdk.org  Mon Feb 20 17:56:55 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 20 Feb 2023 17:56:55 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset [v2]
In-Reply-To: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
Message-ID: <Y7qZo9IJYdW6f1pCgyo2iy7CwaOEK4ghXiWCxv5dQrU=.763bcaf6-2ba0-46ac-af75-554975816ba3@github.com>

> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
> 
> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
> 
> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
> 
> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
> 
> I need someone to help me open an Issue on JBS. Thank you very much.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12570/files
  - new: https://git.openjdk.org/jdk/pull/12570/files/f28a3f1b..0eea8b8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12570&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12570&range=00-01

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12570.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12570/head:pull/12570

PR: https://git.openjdk.org/jdk/pull/12570

From duke at openjdk.org  Mon Feb 20 17:56:55 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 20 Feb 2023 17:56:55 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset [v2]
In-Reply-To: <CS_tSKalwaZ5HvqjNlPoHKMs5z5oeRMyJLjCT9ZWlkM=.c5f68483-d2be-498a-89b0-093644944168@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
 <CS_tSKalwaZ5HvqjNlPoHKMs5z5oeRMyJLjCT9ZWlkM=.c5f68483-d2be-498a-89b0-093644944168@github.com>
Message-ID: <yElBW7O8Jg1_2E_zv14DvHkK-9yC1LsKyimiFnUWNao=.6c9e7724-682b-4077-8682-7fc1286ac24a@github.com>

On Thu, 16 Feb 2023 08:03:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Glavo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 717:
> 
>> 715:     public final Set<String> aliases() {
>> 716:         if (aliasSet == null)
>> 717:             aliasSet = Set.of(aliases);
> 
> Given that this is racy then it might be better to use a local and avoid someone reading this code puzzling over whether it can return null, e.g.
> 
>         Set<String> aliasSet = this.aliasSet;
>         if (aliasSet == null) {
>             this.aliasSet = aliasSet = Set.of(aliases);
>         }
> 
> You can also drop explicitly initialising it null at line 670.

I have updated the code.

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

PR: https://git.openjdk.org/jdk/pull/12570

From alanb at openjdk.org  Mon Feb 20 18:04:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Feb 2023 18:04:30 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset [v2]
In-Reply-To: <yElBW7O8Jg1_2E_zv14DvHkK-9yC1LsKyimiFnUWNao=.6c9e7724-682b-4077-8682-7fc1286ac24a@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
 <CS_tSKalwaZ5HvqjNlPoHKMs5z5oeRMyJLjCT9ZWlkM=.c5f68483-d2be-498a-89b0-093644944168@github.com>
 <yElBW7O8Jg1_2E_zv14DvHkK-9yC1LsKyimiFnUWNao=.6c9e7724-682b-4077-8682-7fc1286ac24a@github.com>
Message-ID: <u5JV7ieS3faZb5ADqlwDjkZKSGMg1YaDfKYbKLUPZaQ=.abd9ae65-00c1-4bf5-9bb5-c0d532be41d6@github.com>

On Mon, 20 Feb 2023 17:51:40 GMT, Glavo <duke at openjdk.org> wrote:

> I have updated the code.

Thanks for the update. I think it looks okay although "as" looks a bit strange here, I think I would use aliasSet or something better.

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

PR: https://git.openjdk.org/jdk/pull/12570

From duke at openjdk.org  Mon Feb 20 18:34:52 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 20 Feb 2023 18:34:52 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset [v3]
In-Reply-To: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
Message-ID: <iQOywf6GOpbTfEeH9KtLOZI91BOj3-xI5yT27dMlDAg=.aaf2a55e-8a6e-4dbb-96f1-404cee0ca846@github.com>

> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
> 
> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
> 
> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
> 
> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
> 
> I need someone to help me open an Issue on JBS. Thank you very much.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12570/files
  - new: https://git.openjdk.org/jdk/pull/12570/files/0eea8b8c..fdb423d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12570&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12570&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12570.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12570/head:pull/12570

PR: https://git.openjdk.org/jdk/pull/12570

From duke at openjdk.org  Mon Feb 20 18:34:53 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 20 Feb 2023 18:34:53 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset [v3]
In-Reply-To: <u5JV7ieS3faZb5ADqlwDjkZKSGMg1YaDfKYbKLUPZaQ=.abd9ae65-00c1-4bf5-9bb5-c0d532be41d6@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
 <CS_tSKalwaZ5HvqjNlPoHKMs5z5oeRMyJLjCT9ZWlkM=.c5f68483-d2be-498a-89b0-093644944168@github.com>
 <yElBW7O8Jg1_2E_zv14DvHkK-9yC1LsKyimiFnUWNao=.6c9e7724-682b-4077-8682-7fc1286ac24a@github.com>
 <u5JV7ieS3faZb5ADqlwDjkZKSGMg1YaDfKYbKLUPZaQ=.abd9ae65-00c1-4bf5-9bb5-c0d532be41d6@github.com>
Message-ID: <nk6WvFyw7XaWpN5PEluCr3bB_s2J9ykZDr0RUcoZIn4=.1e973b00-e0d6-4bf9-ba08-0e35c4bcc4c2@github.com>

On Mon, 20 Feb 2023 18:01:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I have updated the code.
> 
> Thanks for the update. I think it looks okay although "as" looks a bit strange here, I think I would use aliasSet or something better.

Well, the name `as` is a bit strange. I didn't use the name `aliasSet` because I didn't want to shadow the field. 

Now I simply name it `set`. I think this name is clear enough in this context.

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

PR: https://git.openjdk.org/jdk/pull/12570

From alanb at openjdk.org  Mon Feb 20 19:23:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Feb 2023 19:23:26 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset [v3]
In-Reply-To: <iQOywf6GOpbTfEeH9KtLOZI91BOj3-xI5yT27dMlDAg=.aaf2a55e-8a6e-4dbb-96f1-404cee0ca846@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
 <iQOywf6GOpbTfEeH9KtLOZI91BOj3-xI5yT27dMlDAg=.aaf2a55e-8a6e-4dbb-96f1-404cee0ca846@github.com>
Message-ID: <3OLhO8tSjpIrWUG6yAasXE-12PVdoQ__Y8aPSoAEvd8=.505b9f22-1765-4100-b9f6-1dc8d7ef34cd@github.com>

On Mon, 20 Feb 2023 18:34:52 GMT, Glavo <duke at openjdk.org> wrote:

>> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
>> 
>> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
>> 
>> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
>> 
>> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
>> 
>> I need someone to help me open an Issue on JBS. Thank you very much.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12570

From alanb at openjdk.org  Mon Feb 20 19:57:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Feb 2023 19:57:28 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw when
 the channel is closed
Message-ID: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>

This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.

The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12674/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12674&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8280113
  Stats: 122 lines in 2 files changed: 115 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12674.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12674/head:pull/12674

PR: https://git.openjdk.org/jdk/pull/12674

From jpai at openjdk.org  Tue Feb 21 07:20:27 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Feb 2023 07:20:27 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed
In-Reply-To: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
Message-ID: <B7lQZHciQA28Jy72nLXDBXS4FeI-wxl3jhYq8V_iAsA=.e69f3ef3-0848-4b58-b406-1441fccda72d@github.com>

On Mon, 20 Feb 2023 18:09:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
> 
> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.

test/jdk/java/nio/channels/DatagramChannel/AdaptorAsyncCloseAfterReceive.java line 83:

> 81:             // schedule socket to be closed while main thead blocked in receive
> 82:             DatagramSocket s = dc.socket();
> 83:             Future<?> future = scheduler.schedule(() -> s.close(), 1, TimeUnit.SECONDS);

Hello Alan, would it be a good idea to schedule this close as late as possible, just before the call to `s.receive(p)`? On heavily loaded systems, that would then prevent potential intermittent failures where this `s.close()` task could get fired before the control reaches `s.setSoTimeout(timeout)` and the `setSoTimeout(...)` thus would fail with a `SocketException`.

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

PR: https://git.openjdk.org/jdk/pull/12674

From alanb at openjdk.org  Tue Feb 21 07:26:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 07:26:28 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed
In-Reply-To: <B7lQZHciQA28Jy72nLXDBXS4FeI-wxl3jhYq8V_iAsA=.e69f3ef3-0848-4b58-b406-1441fccda72d@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
 <B7lQZHciQA28Jy72nLXDBXS4FeI-wxl3jhYq8V_iAsA=.e69f3ef3-0848-4b58-b406-1441fccda72d@github.com>
Message-ID: <00_l-zOI1C15mMwN5kODwm0AZ54WWvxSyUsQTFA6Xkc=.f9c00e19-d435-4126-b41c-e359ce53b199@github.com>

On Tue, 21 Feb 2023 07:18:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
>> 
>> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.
>
> test/jdk/java/nio/channels/DatagramChannel/AdaptorAsyncCloseAfterReceive.java line 83:
> 
>> 81:             // schedule socket to be closed while main thead blocked in receive
>> 82:             DatagramSocket s = dc.socket();
>> 83:             Future<?> future = scheduler.schedule(() -> s.close(), 1, TimeUnit.SECONDS);
> 
> Hello Alan, would it be a good idea to schedule this `close()` as late as possible, just before the call to `s.receive(p)`? On heavily loaded systems, that would then prevent potential intermittent failures where this `s.close()` task could get fired before the control reaches `s.setSoTimeout(timeout)` and the `setSoTimeout(...)` thus would fail with a `SocketException`.

That's a good point, it should be after the setSoTimeout to avoid an intermittent failure on a very slow/overloaded test machine.

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

PR: https://git.openjdk.org/jdk/pull/12674

From jpai at openjdk.org  Tue Feb 21 07:43:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Feb 2023 07:43:30 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed
In-Reply-To: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
Message-ID: <7PDCPYvE7GI_2zBYvKHhQ3KSc8D-lVAfcJKngepEaW4=.fa53b1b8-c2f3-4e6f-b2de-5c7a3dd9545b@github.com>

On Mon, 20 Feb 2023 18:09:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
> 
> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.

test/jdk/java/nio/channels/DatagramChannel/AdaptorAsyncCloseAfterReceive.java line 81:

> 79:             populateSocketAddressCaches(dc);
> 80: 
> 81:             // schedule socket to be closed while main thead blocked in receive

Trivial typo - "thead" -> "thread"

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

PR: https://git.openjdk.org/jdk/pull/12674

From alanb at openjdk.org  Tue Feb 21 07:49:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 07:49:26 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset
In-Reply-To: <-VsyWuvNrYCcyfF3zyuzSCVybPF4IL8z79z771fAsPw=.3d42df7d-aef8-49aa-99ca-49e0b0e796e1@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
 <-VsyWuvNrYCcyfF3zyuzSCVybPF4IL8z79z771fAsPw=.3d42df7d-aef8-49aa-99ca-49e0b0e796e1@github.com>
Message-ID: <-cED1pPwlETGoCNEWrzW0IEY4PijZgHqe2x1Fr4fLi8=.ab250fd7-5d02-4396-a149-b667f1814108@github.com>

On Wed, 15 Feb 2023 19:25:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
>> 
>> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
>> 
>> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
>> 
>> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
>> 
>> I need someone to help me open an Issue on JBS. Thank you very much.
>
> Good cleanup. Filed an issue: https://bugs.openjdk.org/browse/JDK-8302603

I can sponsor but I'm giving maintainers in this area, e.g. @naotoj, a chance to comment.

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

PR: https://git.openjdk.org/jdk/pull/12570

From alanb at openjdk.org  Tue Feb 21 08:06:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 08:06:59 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed [v2]
In-Reply-To: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
Message-ID: <wsTj2MfBoOHVURxJ6l5CaDmaRzs3hBrMFTD96wJRAmk=.42ddea9f-f308-4fd6-87d8-6430a60980da@github.com>

> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
> 
> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Update test to eliminate potential ffor setSoTimeout throwing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12674/files
  - new: https://git.openjdk.org/jdk/pull/12674/files/2e0861b2..1990f4f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12674&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12674&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12674.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12674/head:pull/12674

PR: https://git.openjdk.org/jdk/pull/12674

From jpai at openjdk.org  Tue Feb 21 08:32:27 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Feb 2023 08:32:27 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed [v2]
In-Reply-To: <wsTj2MfBoOHVURxJ6l5CaDmaRzs3hBrMFTD96wJRAmk=.42ddea9f-f308-4fd6-87d8-6430a60980da@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
 <wsTj2MfBoOHVURxJ6l5CaDmaRzs3hBrMFTD96wJRAmk=.42ddea9f-f308-4fd6-87d8-6430a60980da@github.com>
Message-ID: <2NPYvBbWRzSyI2GDm8YmmuJovNwwE2b06820Yr9n3iU=.3d70619f-84da-40fb-8d17-534fca104aa4@github.com>

On Tue, 21 Feb 2023 08:06:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
>> 
>> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test to eliminate potential ffor setSoTimeout throwing

Thank you Alan for the updates. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12674

From cstein at openjdk.org  Tue Feb 21 10:48:27 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 21 Feb 2023 10:48:27 GMT
Subject: RFR: 8302789: (fs) File.copy should include unsupported copy
 option in exception message
In-Reply-To: <XRGhVKxCvohiWuFybSTLfIg2YQVrJzgD_tfL-4co8PU=.59f68593-12f2-4fc4-9a8d-695e207888a0@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
 <XRGhVKxCvohiWuFybSTLfIg2YQVrJzgD_tfL-4co8PU=.59f68593-12f2-4fc4-9a8d-695e207888a0@github.com>
Message-ID: <xsZvGMks-V4ZlQoz2uLeMc5tP5pX5B2yncoUcDhNCrg=.1d6aac4f-f19b-4495-863e-9715a07e1f7f@github.com>

On Sat, 18 Feb 2023 07:09:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR also fixes the exception message for unsupported move options.
>
> src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 304:
> 
>> 302:             }
>> 303:             if (option == null) throw new NullPointerException();
>> 304:             throw new UnsupportedOperationException("Unsupported move option: " + option);
> 
> The parameter is a CopyOption so changing the message to "move option" might be confusion, maybe just change it to "option"?

Plain "option" might be best here.

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

PR: https://git.openjdk.org/jdk/pull/12625

From cstein at openjdk.org  Tue Feb 21 10:59:53 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 21 Feb 2023 10:59:53 GMT
Subject: RFR: 8302789: (fs) Files.copy should include unsupported copy
 option in exception message [v2]
In-Reply-To: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
Message-ID: <vHx-ZfOIrr3c_699m01C5i5V5CxmPF4WFpV1huc0MIg=.4d799b74-4afe-47e4-9f3a-48236e3cb2b9@github.com>

> This PR also adds the names of unsupported copy options to the the exception message for "Files::move" methods.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Address feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12625/files
  - new: https://git.openjdk.org/jdk/pull/12625/files/0685b858..03accc26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12625&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12625&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12625.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12625/head:pull/12625

PR: https://git.openjdk.org/jdk/pull/12625

From stsypanov at openjdk.org  Tue Feb 21 11:26:08 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 21 Feb 2023 11:26:08 GMT
Subject: RFR: 8302979: Simplify FileChannelLinesSpliterator.SUPPORTED_CHARSETS
 and its usage
Message-ID: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>

Code of `Files.lines()` could be slightly simplified:

- use charsets instead of their names
- use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`

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

Commit messages:
 - Simplify FileChannelLinesSpliterator.SUPPORTED_CHARSETS

Changes: https://git.openjdk.org/jdk/pull/12688/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12688&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302979
  Stats: 11 lines in 2 files changed: 0 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12688.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12688/head:pull/12688

PR: https://git.openjdk.org/jdk/pull/12688

From alanb at openjdk.org  Tue Feb 21 12:06:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 12:06:26 GMT
Subject: RFR: 8302789: (fs) Files.copy should include unsupported copy
 option in exception message [v2]
In-Reply-To: <vHx-ZfOIrr3c_699m01C5i5V5CxmPF4WFpV1huc0MIg=.4d799b74-4afe-47e4-9f3a-48236e3cb2b9@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
 <vHx-ZfOIrr3c_699m01C5i5V5CxmPF4WFpV1huc0MIg=.4d799b74-4afe-47e4-9f3a-48236e3cb2b9@github.com>
Message-ID: <3G0wbhPqAkP6IOak43B1ppgeBY_QvPkLiWv3W-lhIHc=.6d6d3b55-3df2-48d9-b6c8-7276c137e85c@github.com>

On Tue, 21 Feb 2023 10:59:53 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This PR also adds the names of unsupported copy options to the the exception message for "Files::move" methods.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12625

From alanb at openjdk.org  Tue Feb 21 14:24:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 14:24:26 GMT
Subject: RFR: 8302979: Simplify
 FileChannelLinesSpliterator.SUPPORTED_CHARSETS and its usage
In-Reply-To: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
Message-ID: <ytezDFjYf8NJBrGAGklLFC6wB1onXexNRVirI7XiTdY=.f714466c-ec0a-44be-9819-dde4ed36fe17@github.com>

On Tue, 21 Feb 2023 11:20:01 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Code of `Files.lines()` could be slightly simplified:
> 
> - use charsets instead of their names
> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`

Marked as reviewed by alanb (Reviewer).

This looks okay. If cs is null then it should NPE as before. I've moved the JBS issue to the right subcomponent and adjusted the description to make it clear that this is about Files.lines.

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

PR: https://git.openjdk.org/jdk/pull/12688

From alanb at openjdk.org  Tue Feb 21 16:00:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 16:00:26 GMT
Subject: RFR: 8302979: Simplify
 FileChannelLinesSpliterator.SUPPORTED_CHARSETS and its usage
In-Reply-To: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
Message-ID: <gqbbs5atwmzVBRa-SMMfocFuKDQexwYfmDn8XuLqyLc=.b7d00898-42bc-4e65-be18-3dbc0fbb07cb@github.com>

On Tue, 21 Feb 2023 11:20:01 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Code of `Files.lines()` could be slightly simplified:
> 
> - use charsets instead of their names
> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`

@stsypanov Can you fix the description to match the JBS issue?

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

PR: https://git.openjdk.org/jdk/pull/12688

From dfuchs at openjdk.org  Tue Feb 21 16:02:29 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 21 Feb 2023 16:02:29 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed [v2]
In-Reply-To: <wsTj2MfBoOHVURxJ6l5CaDmaRzs3hBrMFTD96wJRAmk=.42ddea9f-f308-4fd6-87d8-6430a60980da@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
 <wsTj2MfBoOHVURxJ6l5CaDmaRzs3hBrMFTD96wJRAmk=.42ddea9f-f308-4fd6-87d8-6430a60980da@github.com>
Message-ID: <PhcTY2IEN05jeZYOECP0tLTmsMflRPyUwmfq5SEmha8=.5560299b-39d3-4d5f-8c20-1bff5c2e92b3@github.com>

On Tue, 21 Feb 2023 08:06:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
>> 
>> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test to eliminate potential ffor setSoTimeout throwing

LGTM. Though we can't rule that this test will fail intermittently if it receives stray datagrams sent by other tests / processes. I wonder if the lambda passed to assertThrows should be modified to return to receive if it receives a datagram whose socket address is not null and not that of `dc`.

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

PR: https://git.openjdk.org/jdk/pull/12674

From stsypanov at openjdk.org  Tue Feb 21 16:08:27 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 21 Feb 2023 16:08:27 GMT
Subject: RFR: 8302979: (fs) Files usage of SUPPORTED_CHARSETS could be
 simplified
In-Reply-To: <gqbbs5atwmzVBRa-SMMfocFuKDQexwYfmDn8XuLqyLc=.b7d00898-42bc-4e65-be18-3dbc0fbb07cb@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
 <gqbbs5atwmzVBRa-SMMfocFuKDQexwYfmDn8XuLqyLc=.b7d00898-42bc-4e65-be18-3dbc0fbb07cb@github.com>
Message-ID: <lzFyj1t_8M8eqvis3Avb9YhkLJ7Rfer_KWtaATn_KPM=.eac1eceb-5bc9-4658-8fcc-3254b07e542e@github.com>

On Tue, 21 Feb 2023 15:57:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Code of `Files.lines()` could be slightly simplified:
>> 
>> - use charsets instead of their names
>> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`
>
> @stsypanov Can you fix the description to match the JBS issue?

@AlanBateman done!

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

PR: https://git.openjdk.org/jdk/pull/12688

From bpb at openjdk.org  Tue Feb 21 16:39:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Feb 2023 16:39:30 GMT
Subject: RFR: 8302789: (fs) Files.copy should include unsupported copy
 option in exception message [v2]
In-Reply-To: <vHx-ZfOIrr3c_699m01C5i5V5CxmPF4WFpV1huc0MIg=.4d799b74-4afe-47e4-9f3a-48236e3cb2b9@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
 <vHx-ZfOIrr3c_699m01C5i5V5CxmPF4WFpV1huc0MIg=.4d799b74-4afe-47e4-9f3a-48236e3cb2b9@github.com>
Message-ID: <hpY7Btc2bTYEw3jk2kcNrCsPPcaBs0OAfQZONfW3Xi4=.e56f4c17-888c-451c-a528-97e08201c0f9@github.com>

On Tue, 21 Feb 2023 10:59:53 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This PR also adds the names of unsupported copy options to the the exception message for "Files::move" methods.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

Looks good now.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12625

From alanb at openjdk.org  Tue Feb 21 16:59:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 16:59:00 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed [v3]
In-Reply-To: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
Message-ID: <DrTG5C_PBQc8EH4PDJyJ8NoWFMIqFaoj2VNW6txPa3w=.3215aafd-b116-450a-b634-b39509d1bd58@github.com>

> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
> 
> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.

Alan Bateman 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 four additional commits since the last revision:

 - Harden test to ignore datagrams from external entities
 - Merge
 - Update test to eliminate potential ffor setSoTimeout throwing
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12674/files
  - new: https://git.openjdk.org/jdk/pull/12674/files/1990f4f0..ac25bf32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12674&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12674&range=01-02

  Stats: 1540 lines in 60 files changed: 1050 ins; 275 del; 215 mod
  Patch: https://git.openjdk.org/jdk/pull/12674.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12674/head:pull/12674

PR: https://git.openjdk.org/jdk/pull/12674

From dfuchs at openjdk.org  Tue Feb 21 16:59:00 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 21 Feb 2023 16:59:00 GMT
Subject: RFR: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed [v3]
In-Reply-To: <DrTG5C_PBQc8EH4PDJyJ8NoWFMIqFaoj2VNW6txPa3w=.3215aafd-b116-450a-b634-b39509d1bd58@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
 <DrTG5C_PBQc8EH4PDJyJ8NoWFMIqFaoj2VNW6txPa3w=.3215aafd-b116-450a-b634-b39509d1bd58@github.com>
Message-ID: <gbBLJnqE2yw4-h-8SHj4m6V05Lt9nahnfgGl1Ppfbws=.57871377-cb60-4284-98fa-a5370ea9a346@github.com>

On Tue, 21 Feb 2023 16:55:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
>> 
>> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.
>
> Alan Bateman 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 four additional commits since the last revision:
> 
>  - Harden test to ignore datagrams from external entities
>  - Merge
>  - Update test to eliminate potential ffor setSoTimeout throwing
>  - Initial commit

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12674

From lancea at openjdk.org  Tue Feb 21 17:01:27 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 21 Feb 2023 17:01:27 GMT
Subject: RFR: 8302789: (fs) Files.copy should include unsupported copy
 option in exception message [v2]
In-Reply-To: <vHx-ZfOIrr3c_699m01C5i5V5CxmPF4WFpV1huc0MIg=.4d799b74-4afe-47e4-9f3a-48236e3cb2b9@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
 <vHx-ZfOIrr3c_699m01C5i5V5CxmPF4WFpV1huc0MIg=.4d799b74-4afe-47e4-9f3a-48236e3cb2b9@github.com>
Message-ID: <-ugVmse6fjFjQ6zUInngE4GAX2nff25uEwm3VvMucuw=.5b85c696-fd3c-4e07-8ec9-428246e00faf@github.com>

On Tue, 21 Feb 2023 10:59:53 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This PR also adds the names of unsupported copy options to the the exception message for "Files::move" methods.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12625

From naoto at openjdk.org  Tue Feb 21 17:36:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 17:36:28 GMT
Subject: RFR: 8302603: Use Set.of in java.nio.charset.Charset [v3]
In-Reply-To: <iQOywf6GOpbTfEeH9KtLOZI91BOj3-xI5yT27dMlDAg=.aaf2a55e-8a6e-4dbb-96f1-404cee0ca846@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
 <iQOywf6GOpbTfEeH9KtLOZI91BOj3-xI5yT27dMlDAg=.aaf2a55e-8a6e-4dbb-96f1-404cee0ca846@github.com>
Message-ID: <Vj0FRiU633QpvJINx-NQ2Q7o2OfG0c9aj_w31fd_g84=.62821d38-f5ca-48e1-b268-845da241cdc7@github.com>

On Mon, 20 Feb 2023 18:34:52 GMT, Glavo <duke at openjdk.org> wrote:

>> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
>> 
>> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
>> 
>> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
>> 
>> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
>> 
>> I need someone to help me open an Issue on JBS. Thank you very much.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

LGTM. Thanks for the fix! I will sponsor it.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12570

From duke at openjdk.org  Tue Feb 21 17:39:39 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 21 Feb 2023 17:39:39 GMT
Subject: Integrated: 8302603: Use Set.of in java.nio.charset.Charset
In-Reply-To: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
References: <HighVu4dwcxUY89YdmJIG3wyKpcLoF_Rp2kvkXEr-4M=.48f13e2a-34da-403a-a978-233e974e23b8@github.com>
Message-ID: <JOX3k9wJd2NtMCTdpc6pfWUFzJjossDkKKn63Cg1bL4=.e6206739-6241-4c9d-aab4-fa89c09cc723@github.com>

On Wed, 15 Feb 2023 09:42:53 GMT, Glavo <duke at openjdk.org> wrote:

> A small patch, using `Set.of` instead of `Collections.unmodifiableSet()` of `Charset#aliasSet`.
> 
> The alias should not be null, and the aliasSet is an immutable copy, so it is safe to use `Set.of`.
> 
> I have investigated all charsets, most of charsets have no more than 4 aliases, and the maximum is only 17.
> 
> In this case, the performance difference between immutable sets and HashSet can be ignored, and the memory footprint of immutable sets is smaller.
> 
> I need someone to help me open an Issue on JBS. Thank you very much.

This pull request has now been integrated.

Changeset: 5489c821
Author:    Glavo <zjx001202 at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5489c821dc2e0c3cfa207dc96d9183d165640368
Stats:     10 lines in 1 file changed: 0 ins; 3 del; 7 mod

8302603: Use Set.of in java.nio.charset.Charset

Reviewed-by: stsypanov, alanb, naoto

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

PR: https://git.openjdk.org/jdk/pull/12570

From bpb at openjdk.org  Tue Feb 21 17:44:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Feb 2023 17:44:55 GMT
Subject: RFR: 8302806: (fs) Remove unused enum
 sun.nio.file.SensitivityWatchEventModifier [v2]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <tf06WYibyZqgHYUYT4h4EkWoyRYDIhsG-JsRPXyRpAU=.458bd37c-1231-4bac-8aec-86a2939cb43b@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: Remove test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/e361bfeb..c980dba9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=00-01

  Stats: 152 lines in 1 file changed: 0 ins; 152 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From cstein at openjdk.org  Tue Feb 21 19:06:39 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 21 Feb 2023 19:06:39 GMT
Subject: Integrated: 8302789: (fs) Files.copy should include unsupported copy
 option in exception message
In-Reply-To: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
References: <7XvbCqQc51p_CV9gQ2qEaa5C9IW7BTiniYnkTY6DyGg=.7e5a2208-91f4-47c4-b6ed-c65ee54b4b27@github.com>
Message-ID: <MgfNEQMhKqxjA2LPiWMl5kVDAqTI1Rf104nSQD7RQR0=.f9c20ed6-ec4d-4d4b-8e88-1825b90564d2@github.com>

On Fri, 17 Feb 2023 20:42:49 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR also adds the names of unsupported copy options to the the exception message for "Files::move" methods.

This pull request has now been integrated.

Changeset: 1ea5f9f7
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ea5f9f7cdaa08d049981d4e331e047455a9885e
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8302789: (fs) Files.copy should include unsupported copy option in exception message

Reviewed-by: alanb, bpb, lancea

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

PR: https://git.openjdk.org/jdk/pull/12625

From duke at openjdk.org  Tue Feb 21 19:39:15 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 21 Feb 2023 19:39:15 GMT
Subject: RFR: 8303024: Use Set.of in WindowsFileSystem
Message-ID: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>

Simply clean up. I need someone to help me open an issue on JBS, thanks.

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

Commit messages:
 - Use Set.of in WindowsFileSystem

Changes: https://git.openjdk.org/jdk/pull/12697/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12697&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303024
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12697.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12697/head:pull/12697

PR: https://git.openjdk.org/jdk/pull/12697

From stsypanov at openjdk.org  Tue Feb 21 19:39:16 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 21 Feb 2023 19:39:16 GMT
Subject: RFR: 8303024: Use Set.of in WindowsFileSystem
In-Reply-To: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
References: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
Message-ID: <JNIWitDYEpVytvk-Q7QRwy4HKgywiN9RqM1DagTZqY8=.8b82a268-f9f5-44fe-be40-caf3f0dcf6b3@github.com>

On Tue, 21 Feb 2023 18:26:59 GMT, Glavo <duke at openjdk.org> wrote:

> Simply clean up. I need someone to help me open an issue on JBS, thanks.

Hi @Glavo, to track this you can use this one https://bugs.openjdk.org/browse/JDK-8303024

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

PR: https://git.openjdk.org/jdk/pull/12697

From duke at openjdk.org  Tue Feb 21 19:39:18 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 21 Feb 2023 19:39:18 GMT
Subject: RFR: 8303024: Use Set.of in WindowsFileSystem
In-Reply-To: <JNIWitDYEpVytvk-Q7QRwy4HKgywiN9RqM1DagTZqY8=.8b82a268-f9f5-44fe-be40-caf3f0dcf6b3@github.com>
References: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
 <JNIWitDYEpVytvk-Q7QRwy4HKgywiN9RqM1DagTZqY8=.8b82a268-f9f5-44fe-be40-caf3f0dcf6b3@github.com>
Message-ID: <BZXlZCvKTzF0ZipUCO4RmF0YTUFQl5S7T9k6UDMfK5c=.1b62c021-01d3-4512-b509-46e8dabc41fb@github.com>

On Tue, 21 Feb 2023 19:28:43 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Hi @Glavo, to track this you can use this one https://bugs.openjdk.org/browse/JDK-8303024

Thanks.

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

PR: https://git.openjdk.org/jdk/pull/12697

From naoto at openjdk.org  Tue Feb 21 19:46:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 19:46:25 GMT
Subject: RFR: 8301119: Support for GB18030-2022
Message-ID: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>

Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

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

Commit messages:
 - Check initPhase and don't call System.getProperty if in phase 1
 - Some clean-up
 - Some more fixes
 - removed unnecessary method name composition
 - Removed unnecessary imports
 - aliases fix
 - Move GB18030 into standard charsets provider
 - indentation
 - Removed unused annotation
 - Removed null check
 - ... and 4 more: https://git.openjdk.org/jdk/compare/574b48c6...0f3c25ce

Changes: https://git.openjdk.org/jdk/pull/12518/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301119
  Stats: 283 lines in 14 files changed: 129 ins; 41 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From tvaleev at openjdk.org  Tue Feb 21 20:39:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 21 Feb 2023 20:39:53 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v3]
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>

> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
> 
> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12633/files
  - new: https://git.openjdk.org/jdk/pull/12633/files/be13683b..e3fb1502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=01-02

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From tvaleev at openjdk.org  Tue Feb 21 20:39:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 21 Feb 2023 20:39:53 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v2]
In-Reply-To: <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
 <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>
Message-ID: <Niq36ljL-AlwQ8DKZmYxEw5D_g0YwcC9gKRn1fzsMyc=.e7fa2da2-f3eb-4313-aaab-4a8154cd20f2@github.com>

On Sun, 19 Feb 2023 08:54:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK
>
>> Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK
> 
> Yes, the jrt file system provider is compiled --release 8 to create lib/jrt-fs.jar. That's the plumbing needed to allow IDEs/tools running on JDK 8 access the contents of a target run-time image as a file system.

@AlanBateman thank you for review! Argh, I always forget about copyright year. Probably it's possible to update jcheck to make this check automated?

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

PR: https://git.openjdk.org/jdk/pull/12633

From bpb at openjdk.org  Tue Feb 21 20:43:26 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Feb 2023 20:43:26 GMT
Subject: RFR: 8303024: Use Set.of in WindowsFileSystem
In-Reply-To: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
References: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
Message-ID: <O25LS3xh028dnVqhTZlWdXDa7d-wkrRWA9AH7wT5BBc=.2bfc79bf-234f-4d04-8209-0a3cf25b7f90@github.com>

On Tue, 21 Feb 2023 18:26:59 GMT, Glavo <duke at openjdk.org> wrote:

> Simply clean up. I need someone to help me open an issue on JBS, thanks.

Looks okay.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12697

From bpb at openjdk.org  Tue Feb 21 20:50:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Feb 2023 20:50:27 GMT
Subject: RFR: 8303024: Use Set.of in WindowsFileSystem
In-Reply-To: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
References: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
Message-ID: <MSPmSFrKHS1VkTRX6jtLHn5FmyEvMtHhPb5LiHgpV5c=.449f3398-d44f-4cbd-82fd-68c9fe35f4e3@github.com>

On Tue, 21 Feb 2023 18:26:59 GMT, Glavo <duke at openjdk.org> wrote:

> Simply clean up. I need someone to help me open an issue on JBS, thanks.

In order to match the JBS issue, the title of this PR should be changed to:

"8303024: (fs) WindowsFileSystem.supportedFileAttributeViews can use Set.of"

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

PR: https://git.openjdk.org/jdk/pull/12697

From jwaters at openjdk.org  Wed Feb 22 07:05:31 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Feb 2023 07:05:31 GMT
Subject: RFR: 8302979: (fs) Files usage of SUPPORTED_CHARSETS could be
 simplified
In-Reply-To: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
Message-ID: <qz7lOgCXE6o05gAdUqQdG4JP1q80TxtR7hTU3agKMRw=.a840b7a3-ce18-40f0-b5b9-4330c184ca1a@github.com>

On Tue, 21 Feb 2023 11:20:01 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Code of `Files.lines()` could be slightly simplified:
> 
> - use charsets instead of their names
> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`

Small nit before sponsoring, perhaps when initializing `SUPPORTED_CHARSETS`, have the charset instances use an indentation of 4 spaces instead of 8

Looks fine to me, doesn't seem like the Set used to store the supported charsets is concerned about having anything added to it, so this should pretty much behave the same as before as Alan said

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

Marked as reviewed by jwaters (Committer).

PR: https://git.openjdk.org/jdk/pull/12688

From stsypanov at openjdk.org  Wed Feb 22 07:38:05 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 22 Feb 2023 07:38:05 GMT
Subject: RFR: 8302979: (fs) Files usage of SUPPORTED_CHARSETS could be
 simplified [v2]
In-Reply-To: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
Message-ID: <rj9fcI7QiLUWY9iEeA2eMCImtHwGJZmhM38rSQzmWX4=.61efac47-b6d0-4542-a9c5-63167e89bacc@github.com>

> Code of `Files.lines()` could be slightly simplified:
> 
> - use charsets instead of their names
> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12688/files
  - new: https://git.openjdk.org/jdk/pull/12688/files/a4a2b389..51803254

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12688&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12688&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12688.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12688/head:pull/12688

PR: https://git.openjdk.org/jdk/pull/12688

From stsypanov at openjdk.org  Wed Feb 22 07:38:09 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 22 Feb 2023 07:38:09 GMT
Subject: RFR: 8302979: (fs) Files usage of SUPPORTED_CHARSETS could be
 simplified
In-Reply-To: <qz7lOgCXE6o05gAdUqQdG4JP1q80TxtR7hTU3agKMRw=.a840b7a3-ce18-40f0-b5b9-4330c184ca1a@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
 <qz7lOgCXE6o05gAdUqQdG4JP1q80TxtR7hTU3agKMRw=.a840b7a3-ce18-40f0-b5b9-4330c184ca1a@github.com>
Message-ID: <MLvr9Q-qXFEHoPFrznBwtn2UjGGSLjGauQDfXKumzVs=.7edfb68a-45eb-4f7f-805b-4f01725901c9@github.com>

On Wed, 22 Feb 2023 07:00:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Code of `Files.lines()` could be slightly simplified:
>> 
>> - use charsets instead of their names
>> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`
>
> Looks fine to me, doesn't seem like the Set used to store the supported charsets is concerned about having anything added to it, so this should pretty much behave the same as before as Alan said

@TheShermanTanker done!

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

PR: https://git.openjdk.org/jdk/pull/12688

From jwaters at openjdk.org  Wed Feb 22 07:43:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Feb 2023 07:43:46 GMT
Subject: RFR: 8302979: (fs) Files usage of SUPPORTED_CHARSETS could be
 simplified [v2]
In-Reply-To: <rj9fcI7QiLUWY9iEeA2eMCImtHwGJZmhM38rSQzmWX4=.61efac47-b6d0-4542-a9c5-63167e89bacc@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
 <rj9fcI7QiLUWY9iEeA2eMCImtHwGJZmhM38rSQzmWX4=.61efac47-b6d0-4542-a9c5-63167e89bacc@github.com>
Message-ID: <UG400PpeoK6zHCLNeJ0AvoHz-GvBziLKhOKnfeiOz-I=.44be7bcc-b411-499f-8988-2cd14443be13@github.com>

On Wed, 22 Feb 2023 07:38:05 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Code of `Files.lines()` could be slightly simplified:
>> 
>> - use charsets instead of their names
>> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Alright, thanks for the fixes :)

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

PR: https://git.openjdk.org/jdk/pull/12688

From alanb at openjdk.org  Wed Feb 22 08:17:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 08:17:11 GMT
Subject: Integrated: 8280113: (dc) DatagramSocket.receive does not always throw
 when the channel is closed
In-Reply-To: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
References: <ihg5rqcl8QrQF2E55MJ242yctS-046k0Wlb24nFkQaI=.c17b3138-fb51-4cd0-b152-29746fdb5c0b@github.com>
Message-ID: <sVloL4ciI7Lhw3hP5hIXB5WjCWwiBnhbOwGGL4eyJoI=.97f62929-2c12-4158-b1a7-7fa66b6bd044@github.com>

On Mon, 20 Feb 2023 18:09:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is an issue with the async close of a DatagramChannel when a thread is blocked in its adaptor's receive method and the underlying socket is non-blocking.  The async close causes poll to wakeup and the underlying receive to return 0 so it can't be distinguished from a receive of a zero-length datagram. The channel state needs to be checked to distinguish the two cases so that AsynchronousCloseException can be thrown if the channel has been closed. The bug goes back to JDK 14 when caching of sockaddr structured was introduced.
> 
> The test case creates the conditions to exercise the case for both the timed and untimed receive. The bug report is the timed case, which receives two datagrams before attempting a timed receive. The harder case to test is the untimed case so the test uses a virtual thread to force the underlying socket to be non-blocking.

This pull request has now been integrated.

Changeset: b6ecca12
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6ecca126846f9c53d554ff061cfe9b7b20a4d12
Stats:     135 lines in 2 files changed: 128 ins; 0 del; 7 mod

8280113: (dc) DatagramSocket.receive does not always throw when the channel is closed

Reviewed-by: jpai, dfuchs

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

PR: https://git.openjdk.org/jdk/pull/12674

From tvaleev at openjdk.org  Wed Feb 22 09:55:00 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 22 Feb 2023 09:55:00 GMT
Subject: Integrated: 8302815 Use new Math.clamp method in core libraries
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <uneJh9xm0xpMTSGWibl3hpkaSaC5iYGsmwF7VaAdspc=.0b5c502d-06fc-4ea7-b3e9-80ae9d02d551@github.com>

On Sat, 18 Feb 2023 10:50:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
> 
> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

This pull request has now been integrated.

Changeset: 3f3a1f53
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f3a1f534b7f2f5be6d7ded9d9832fa9394e763c
Stats:     45 lines in 11 files changed: 0 ins; 8 del; 37 mod

8302815: Use new Math.clamp method in core libraries

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/12633

From alanb at openjdk.org  Wed Feb 22 10:00:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 10:00:31 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <78oXv8oehtNFwbwcPyczGNkWZcLFjxWH4pUDin1KTTI=.ca90d92f-04d2-47cc-8da9-e956f315046f@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 211:

> 209: 
> 210:     // Lazily initialized system property value
> 211:     private static String GB18030_2000;

I assume this should be a stable field.

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

PR: https://git.openjdk.org/jdk/pull/12518

From coffeys at openjdk.org  Wed Feb 22 10:48:55 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 22 Feb 2023 10:48:55 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 217:

> 215:             if (VM.initLevel() < 1) {
> 216:                 // Cannot get the system property yet. Assumes non-2000
> 217:                 GB18030_2000 = "";

curious - what scenario triggers this call at initLevel < 1 ? would it be better to simply return "false" at that time and leave the GB18030_2000 variable to be set once we're at initLevel >=1  ?  -- or perhaps that would invalidate the workflow of the original caller (which called in at initLevel <1)

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

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Wed Feb 22 11:38:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 11:38:14 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
Message-ID: <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>

On Wed, 22 Feb 2023 10:46:10 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> curious - what scenario triggers this call at initLevel < 1 ?

It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.

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

PR: https://git.openjdk.org/jdk/pull/12518

From jwaters at openjdk.org  Wed Feb 22 14:09:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Feb 2023 14:09:07 GMT
Subject: RFR: 8302979: (fs) Files usage of SUPPORTED_CHARSETS could be
 simplified [v2]
In-Reply-To: <rj9fcI7QiLUWY9iEeA2eMCImtHwGJZmhM38rSQzmWX4=.61efac47-b6d0-4542-a9c5-63167e89bacc@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
 <rj9fcI7QiLUWY9iEeA2eMCImtHwGJZmhM38rSQzmWX4=.61efac47-b6d0-4542-a9c5-63167e89bacc@github.com>
Message-ID: <YPc7KHs7TTypB9OzOZAjLSNskRLF2n44ITUn52RcHCE=.c1f105f5-621d-4781-a866-fa02091d1a24@github.com>

On Wed, 22 Feb 2023 07:38:05 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Code of `Files.lines()` could be slightly simplified:
>> 
>> - use charsets instead of their names
>> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Marked as reviewed by jwaters (Committer).

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

PR: https://git.openjdk.org/jdk/pull/12688

From stsypanov at openjdk.org  Wed Feb 22 14:13:29 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 22 Feb 2023 14:13:29 GMT
Subject: Integrated: 8302979: (fs) Files usage of SUPPORTED_CHARSETS could be
 simplified
In-Reply-To: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
References: <ZHxqRNCzO538oeY90CWVgo17evTDNEVU-9jsWXoc5P4=.989ee81f-accc-490d-bb01-359237f67d1d@github.com>
Message-ID: <yLUKH98LUYh-4-NLAwAZ2oUKfMAXUB_9_9MBScbjQMY=.048d9831-a81c-4934-ad05-9be799cc19fa@github.com>

On Tue, 21 Feb 2023 11:20:01 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Code of `Files.lines()` could be slightly simplified:
> 
> - use charsets instead of their names
> - use `Set.of()` instead of `HashSet` in `FileChannelLinesSpliterator`

This pull request has now been integrated.

Changeset: 25bfed3b
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25bfed3b123ed64055b22c8a9723835d4410362c
Stats:     11 lines in 2 files changed: 0 ins; 3 del; 8 mod

8302979: (fs) Files usage of SUPPORTED_CHARSETS could be simplified

Reviewed-by: alanb, jwaters

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

PR: https://git.openjdk.org/jdk/pull/12688

From redestad at openjdk.org  Wed Feb 22 15:06:35 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 22 Feb 2023 15:06:35 GMT
Subject: RFR: 8303073: (bf) Temporarily reinstate private
 DirectByteBuffer(long, int) constructor
Message-ID: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>

We have a dependency on the renaissance benchmark suite for performance regression testing, which in turn has a dependency on a version of Spark that calls a private constructor that was recently chaned. To facilitate ongoing regression testing we want to temporarily put back a constructor with the old signature.

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

Commit messages:
 - (bf) Temporarily reinstate private DirectByteBuffer(long, int) constructor

Changes: https://git.openjdk.org/jdk/pull/12717/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12717&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303073
  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12717.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12717/head:pull/12717

PR: https://git.openjdk.org/jdk/pull/12717

From redestad at openjdk.org  Wed Feb 22 15:06:38 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 22 Feb 2023 15:06:38 GMT
Subject: RFR: 8303073: (bf) Temporarily reinstate private
 DirectByteBuffer(long, int) constructor
In-Reply-To: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
References: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
Message-ID: <24ObYeMi8Q-RiYzKSqmWgZuOEOHvangK5Y90DuYumAY=.d71c9460-811c-4a3b-97ce-2ba9fea0e7b0@github.com>

On Wed, 22 Feb 2023 14:30:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We have a dependency on the renaissance benchmark suite for performance regression testing, which in turn has a dependency on a version of Spark that calls a private constructor that was recently chaned. To facilitate ongoing regression testing we want to temporarily put back a constructor with the old signature.

Intent is to remove this before stabilization.

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

PR: https://git.openjdk.org/jdk/pull/12717

From prappo at openjdk.org  Wed Feb 22 15:22:20 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Feb 2023 15:22:20 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v3]
In-Reply-To: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
Message-ID: <He-VgS2FvvHi-RPJtoeJpwVI-U6A_xkjLEGNGg0HRsI=.19cf5b10-85b5-49f9-b737-91b8b63b2fc5@github.com>

On Tue, 21 Feb 2023 20:39:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
>> 
>> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I only saw this PR after it has been integrated. A code location that immediately came to mind but was missing in the change is this java/util/concurrent/SubmissionPublisher.java:1273:

       public final void request(long n) {
            if (n > 0L) {
                for (;;) {
                    long p = demand, d = p + n;  // saturate
                    if (casDemand(p, d < p ? Long.MAX_VALUE : d))
                        break;
                }
                startOnSignal(RUN | ACTIVE | REQS);
            }
            else
                onError(new IllegalArgumentException(
                            "non-positive subscription request"));
        }

Seems like a poster child for the new Math.clamp functionality.

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

PR: https://git.openjdk.org/jdk/pull/12633

From alanb at openjdk.org  Wed Feb 22 15:22:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 15:22:04 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <TEAzveqaYCtriT9l0ikO71z2k7_mBhd5AD6s2t-YPyw=.253b065a-90f1-4f84-a7de-fdc71326d91d@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Overall I think it looks very good, just StandardCharsets.isGB18030_2000 needs attention. Having GB18030 be in java.base in all builds, rather than everywhere except macOS, is okay and makes things a lot simpler.

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

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Wed Feb 22 15:33:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 15:33:04 GMT
Subject: RFR: 8303073: (bf) Temporarily reinstate private
 DirectByteBuffer(long, int) constructor
In-Reply-To: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
References: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
Message-ID: <nbylWwDDwJjmqM_0LwSSGyVmFQRI3a4LOdUiwKSJyX4=.44018856-5e3b-4a38-a8a7-e36e16b61d64@github.com>

On Wed, 22 Feb 2023 14:30:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We have a dependency on the renaissance benchmark suite for performance regression testing, which in turn has a dependency on a version of Spark that calls a private constructor that was recently chaned. To facilitate ongoing regression testing we want to temporarily put back a constructor with the old signature.

Marked as reviewed by alanb (Reviewer).

I don't mind if this is temporarily re-instated but we somehow need to get a bug submitted to Apache Spark on this.  Their JBS doesn't have public signup so we can't do it.

We should create a JBS to remove this constructor so it doesn't get forgotten.

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

PR: https://git.openjdk.org/jdk/pull/12717

From prappo at openjdk.org  Wed Feb 22 15:51:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Feb 2023 15:51:32 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v3]
In-Reply-To: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
Message-ID: <l_a3OOnnWIBEV5S43T_ZYSxD_uSEAt36wCBc0VG_v4M=.dbe3fc8b-95ce-431b-9bfd-d01ca815aa29@github.com>

On Tue, 21 Feb 2023 20:39:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
>> 
>> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

On second thought, maybe not; Math.clamp might actually look more clumsy here. Scratch my previous comment.

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

PR: https://git.openjdk.org/jdk/pull/12633

From bpb at openjdk.org  Wed Feb 22 16:07:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 16:07:50 GMT
Subject: RFR: 8303073: (bf) Temporarily reinstate private
 DirectByteBuffer(long, int) constructor
In-Reply-To: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
References: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
Message-ID: <EpnxLHPJxQZa7iHzrCWnZqKnt7DSTT4IEvaGxUtCIU8=.dfc64bc1-e763-4718-ade7-e93c14681afd@github.com>

On Wed, 22 Feb 2023 14:30:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We have a dependency on the renaissance benchmark suite for performance regression testing, which in turn has a dependency on a version of Spark that calls a private constructor that was recently chaned. To facilitate ongoing regression testing we want to temporarily put back a constructor with the old signature.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12717

From bpb at openjdk.org  Wed Feb 22 16:19:00 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 16:19:00 GMT
Subject: RFR: 8303073: (bf) Temporarily reinstate private
 DirectByteBuffer(long, int) constructor
In-Reply-To: <nbylWwDDwJjmqM_0LwSSGyVmFQRI3a4LOdUiwKSJyX4=.44018856-5e3b-4a38-a8a7-e36e16b61d64@github.com>
References: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
 <nbylWwDDwJjmqM_0LwSSGyVmFQRI3a4LOdUiwKSJyX4=.44018856-5e3b-4a38-a8a7-e36e16b61d64@github.com>
Message-ID: <BKzT2uo7R_9MnV2sFrJfaghHp1wVLM9CX7XpRhgqBNo=.1bc7fbc2-ff14-4eab-af1d-47312e951275@github.com>

On Wed, 22 Feb 2023 15:28:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We should create a JBS to remove this constructor so it doesn't get forgotten.

Done: JDK-8303083.

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

PR: https://git.openjdk.org/jdk/pull/12717

From duke at openjdk.org  Wed Feb 22 17:22:17 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 22 Feb 2023 17:22:17 GMT
Subject: Integrated: 8303024: (fs)
 WindowsFileSystem.supportedFileAttributeViews can use Set.of
In-Reply-To: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
References: <CicmvAIftL-2cnHF0DzLkgSeEri-Y6wQH1oRQ0uIMCQ=.205ae3c5-6d24-4f6f-b0be-675499f1c8d4@github.com>
Message-ID: <jXLHWDQ9mcxLhst73qNjcknviYPsY-jyQ87klW12iIM=.3f192840-b027-4098-b0d8-4effba166538@github.com>

On Tue, 21 Feb 2023 18:26:59 GMT, Glavo <duke at openjdk.org> wrote:

> Simply clean up. I need someone to help me open an issue on JBS, thanks.

This pull request has now been integrated.

Changeset: f893d231
Author:    Glavo <zjx001202 at gmail.com>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f893d2315db914e946825e57e53313e1a69f5eb6
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8303024: (fs) WindowsFileSystem.supportedFileAttributeViews can use Set.of

Reviewed-by: bpb

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

PR: https://git.openjdk.org/jdk/pull/12697

From naoto at openjdk.org  Wed Feb 22 18:22:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 18:22:33 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <zjw9cgUgI3rGDV9gW7xcpCuSpDeBi10TK7AZoSjP970=.81f3937a-b471-4bf7-8bc5-ebaf0c9f0ae7@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato 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 16 additional commits since the last revision:

 - Add @Stable annotation
 - Merge branch 'master' into JDK-8301119-GB18030-2022
 - Check initPhase and don't call System.getProperty if in phase 1
 - Some clean-up
 - Some more fixes
 - removed unnecessary method name composition
 - Removed unnecessary imports
 - aliases fix
 - Move GB18030 into standard charsets provider
 - indentation
 - ... and 6 more: https://git.openjdk.org/jdk/compare/0981ec17...b5379b69

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/0f3c25ce..b5379b69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=00-01

  Stats: 8209 lines in 333 files changed: 4912 ins; 1488 del; 1809 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Wed Feb 22 18:22:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 18:22:41 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
Message-ID: <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>

On Wed, 22 Feb 2023 11:34:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 217:
>> 
>>> 215:             if (VM.initLevel() < 1) {
>>> 216:                 // Cannot get the system property yet. Assumes non-2000
>>> 217:                 GB18030_2000 = "";
>> 
>> curious - what scenario triggers this call at initLevel < 1 ? would it be better to simply return "false" at that time and leave the GB18030_2000 variable to be set once we're at initLevel >=1  ?  -- or perhaps that would invalidate the workflow of the original caller (which called in at initLevel <1)
>
>> curious - what scenario triggers this call at initLevel < 1 ?
> 
> It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.

`Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.

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

PR: https://git.openjdk.org/jdk/pull/12518

From bpb at openjdk.org  Wed Feb 22 23:05:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 23:05:07 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v17]
In-Reply-To: <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
Message-ID: <axdBjQB5JkXmqazIOhvJvqj3g92sN6CzNx-lZOMRDhU=.5d75ddb7-ea49-4515-986d-788dd08437c4@github.com>

On Sun, 11 Dec 2022 15:18:54 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Implementing 8278268
>   
>   Signed-off-by: Markus Karg <markus at headcrashing.eu>

test/jdk/java/nio/channels/Channels/TransferTo2.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

The copyright years need to be updated per the usual convention in all files in this PR.

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

PR: https://git.openjdk.org/jdk/pull/6711

From bpb at openjdk.org  Wed Feb 22 23:05:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 23:05:03 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v17]
In-Reply-To: <iXUTs9909Egth2l6i-M6yiP4sSSzrRZ7cimnB8FmpWA=.3ada411e-d773-41d3-9c16-2a3c8a49b1bb@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
 <Jh7qxHwulfAXfKht0DbUkNwjd6JHucLHxQnanqngwvQ=.c75f6016-b88c-4c4a-a296-9f28edd14327@github.com>
 <iXUTs9909Egth2l6i-M6yiP4sSSzrRZ7cimnB8FmpWA=.3ada411e-d773-41d3-9c16-2a3c8a49b1bb@github.com>
Message-ID: <ftxjNY7N0Miq3rza02v6SvTmniyPK422AndQLz19Dqs=.303e3d54-eea3-48f7-9262-c2465fd49b0a@github.com>

On Fri, 17 Feb 2023 16:50:44 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Which platform was used to generate the performance data? Also what was the source stream? Just asking as FileChannel.transferFrom uses copy_file_range for file-to-file (Linux), memory mapping for file-to-file, and a copy loop for other cases.
>> 
>> In any case, the changes to ChannelInputStream.transferTo does the right thing. Most of the change in the PR is the tests. I don't have time to look at those closely right now but Lance or Brian might have cycles.
>
> @AlanBateman @LanceAndersen Kindly asking to resume this MR. Thanks! :-)

@mkarg: Comments from @LanceAndersen on 2 January 2022:

> I haven't gone through this in detail, but we want to merge The remaining TransferTo2 tests into TransferTo. For the large File tests, any duplicate code can also be included in the base class.

Unless I missed it somehow, I don't see that this has been addressed. Is there an intent to perform the suggested test merging and duplicate code consolidation?

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

PR: https://git.openjdk.org/jdk/pull/6711

From bpb at openjdk.org  Wed Feb 22 23:35:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 23:35:08 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v3]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <BT4PUVkkM9_OrNDbIdxPEXYwNzDdBNbF4z1HtaVPw7E=.160b64c6-88ad-4132-9634-3dba35778190@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: Remove sensitivity from PollingWatchService

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/c980dba9..e17f66c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=01-02

  Stats: 21 lines in 1 file changed: 1 ins; 8 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From alanb at openjdk.org  Thu Feb 23 07:17:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 07:17:06 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v3]
In-Reply-To: <BT4PUVkkM9_OrNDbIdxPEXYwNzDdBNbF4z1HtaVPw7E=.160b64c6-88ad-4132-9634-3dba35778190@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
 <BT4PUVkkM9_OrNDbIdxPEXYwNzDdBNbF4z1HtaVPw7E=.160b64c6-88ad-4132-9634-3dba35778190@github.com>
Message-ID: <8-1tIXrVyhqH-Gp2xrkyHGCe5AsprzTXamgDpxxUHsc=.bf94a017-5730-4954-8e2e-d2384cba5653@github.com>

On Wed, 22 Feb 2023 23:35:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This enum is not used in the JDK and did not appear in external source code searches.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302806: Remove sensitivity from PollingWatchService

You need remove the SENSITIVITY_xxx constants from sun.nio.fs.ExtendedOptions and that will should help identify the code in the polling WatchService implementation that need to be removed.

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

PR: https://git.openjdk.org/jdk/pull/12626

From redestad at openjdk.org  Thu Feb 23 08:35:04 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 08:35:04 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
Message-ID: <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>

On Wed, 22 Feb 2023 17:52:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> curious - what scenario triggers this call at initLevel < 1 ?
>> 
>> It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.
>
> `Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.

`@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.

I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.

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

PR: https://git.openjdk.org/jdk/pull/12518

From redestad at openjdk.org  Thu Feb 23 08:58:02 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 08:58:02 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
Message-ID: <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>

On Thu, 23 Feb 2023 08:32:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.
>
> `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.
> 
> I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.

Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:


    isGB18030_2000() { return GB18030Properties.GB18030_2000; }

    private static class GB18030Properties {
        private static final GB18030_2000 = init();
        private static boolean init() {
            if (VM.initLevel() < 1) {
                // Cannot get the system property yet. Assumes non-2000
                return false;
            }
            return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
        }
    }

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

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Thu Feb 23 09:07:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 09:07:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
Message-ID: <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>

On Thu, 23 Feb 2023 08:55:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.
>> 
>> I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.
>
> Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:
> 
> 
>     isGB18030_2000() { return GB18030Properties.GB18030_2000; }
> 
>     private static class GB18030Properties {
>         private static final GB18030_2000 = init();
>         private static boolean init() {
>             if (VM.initLevel() < 1) {
>                 // Cannot get the system property yet. Assumes non-2000
>                 return false;
>             }
>             return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
>         }
>     }

Right, doing nothing for the initLevel < 1 case means that  `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers.

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

PR: https://git.openjdk.org/jdk/pull/12518

From coffeys at openjdk.org  Thu Feb 23 09:51:06 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 23 Feb 2023 09:51:06 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
Message-ID: <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>

On Thu, 23 Feb 2023 09:03:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:
>> 
>> 
>>     isGB18030_2000() { return GB18030Properties.GB18030_2000; }
>> 
>>     private static class GB18030Properties {
>>         private static final GB18030_2000 = init();
>>         private static boolean init() {
>>             if (VM.initLevel() < 1) {
>>                 // Cannot get the system property yet. Assumes non-2000
>>                 return false;
>>             }
>>             return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
>>         }
>>     }
>
> Right, doing nothing for the initLevel < 1 case means that  `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers.

would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?

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

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Thu Feb 23 10:10:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 10:10:08 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
 <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
Message-ID: <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>

On Thu, 23 Feb 2023 09:48:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?

The early startup scenario is early in the system property initialization, specifically SystemProps.Raw.<clinit> which will cause the encoding to be initialized. This has to avoid make use of system properties, otherwise you get a circular initialization issue.

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

PR: https://git.openjdk.org/jdk/pull/12518

From redestad at openjdk.org  Thu Feb 23 10:34:23 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 10:34:23 GMT
Subject: RFR: 8303073: (bf) Temporarily reinstate private
 DirectByteBuffer(long, int) constructor
In-Reply-To: <BKzT2uo7R_9MnV2sFrJfaghHp1wVLM9CX7XpRhgqBNo=.1bc7fbc2-ff14-4eab-af1d-47312e951275@github.com>
References: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
 <nbylWwDDwJjmqM_0LwSSGyVmFQRI3a4LOdUiwKSJyX4=.44018856-5e3b-4a38-a8a7-e36e16b61d64@github.com>
 <BKzT2uo7R_9MnV2sFrJfaghHp1wVLM9CX7XpRhgqBNo=.1bc7fbc2-ff14-4eab-af1d-47312e951275@github.com>
Message-ID: <5TJz8Z-GZRvBXOZHtIToaZ4x7vKnG080erWwKdEw2C8=.986d1253-a364-4454-8685-c16567d88841@github.com>

On Wed, 22 Feb 2023 16:16:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I don't mind if this is temporarily re-instated but we somehow need to get a bug submitted to Apache Spark on this.  Their JBS doesn't have public signup so we can't do it.
>> 
>> We should create a JBS to remove this constructor so it doesn't get forgotten.
>
>> We should create a JBS to remove this constructor so it doesn't get forgotten.
> 
> Done: JDK-8303083.

Thanks for reviewing, and thanks @bplb for filing the bug to revert this in due time.

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

PR: https://git.openjdk.org/jdk/pull/12717

From redestad at openjdk.org  Thu Feb 23 10:34:25 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 10:34:25 GMT
Subject: Integrated: 8303073: (bf) Temporarily reinstate private
 DirectByteBuffer(long, int) constructor
In-Reply-To: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
References: <EWj0Os9Wo1vQYjkeqSiDhRc-Fp48jj_Fv0G63k6FqA8=.d85b1aaa-3873-41a3-acbc-70f8a14e5cbb@github.com>
Message-ID: <0Ra0P3OUj_XvMlYNtC4SJfhysNRt8d9XvWXgvTy2ApE=.db84fd91-f9b3-486e-b2c3-35a10920fbe2@github.com>

On Wed, 22 Feb 2023 14:30:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We have a dependency on the renaissance benchmark suite for performance regression testing, which in turn has a dependency on a version of Spark that calls a private constructor that was recently chaned. To facilitate ongoing regression testing we want to temporarily put back a constructor with the old signature.

This pull request has now been integrated.

Changeset: 1bab93b2
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bab93b2d0ca62189fee1783d8796d056353c72e
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8303073: (bf) Temporarily reinstate private DirectByteBuffer(long, int) constructor

Reviewed-by: alanb, bpb

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

PR: https://git.openjdk.org/jdk/pull/12717

From bpb at openjdk.org  Thu Feb 23 17:48:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Feb 2023 17:48:57 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v4]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <ydNj1FoAdu1gQKM45mV7gC0hyWDIWyDv0WoOcVZ3LpY=.ccd4b67e-b179-4a95-a201-1f055eba6f11@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: Remove ExtendedOptions.SENSITIViTY_xxx and things depending on it

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/e17f66c1..6172ac39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=02-03

  Stats: 36 lines in 5 files changed: 2 ins; 22 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From naoto at openjdk.org  Thu Feb 23 19:34:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 19:34:44 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Moved the 2000 flag into GB18030

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/b5379b69..4d4015a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=01-02

  Stats: 28 lines in 3 files changed: 6 ins; 18 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Thu Feb 23 19:36:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 19:36:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
 <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
 <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>
Message-ID: <B4IvJCeiXPoSRP0Zr5eaSdK6GzcoWoZ6jjytYs80yxw=.546521a6-49b5-4aaf-8b3a-09ddc25aa5d3@github.com>

On Thu, 23 Feb 2023 10:07:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?
>
>> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?
> 
> The early startup scenario is early in the system property initialization, specifically SystemProps.Raw.<clinit> which will cause the encoding to be initialized. This has to avoid make use of system properties, otherwise you get a circular initialization issue.

> what this code is really reaching for is `static final` field semantics.

Exactly. Introducing the holder pattern in `StandardCharset` would solve the issue, but instead I moved the flag init into `GB18030` so that we can literally make it `static final`.

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

PR: https://git.openjdk.org/jdk/pull/12518

From bpb at openjdk.org  Thu Feb 23 21:16:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Feb 2023 21:16:41 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v5]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <W_HuvqiPNipq0E96Q8HUay1iwMrrF2STlKNDYd-D8z0=.0cb78060-fbd1-4070-9397-581c1ba8e5b9@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: Remove modifier loops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/6172ac39..20c9ced3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=03-04

  Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From bpb at openjdk.org  Thu Feb 23 21:32:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Feb 2023 21:32:52 GMT
Subject: RFR: 8029370: (fc) FileChannel javadoc not clear for cases where
 position == size
Message-ID: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>

Modify the specifications of the `java.nio.channels.FileChannel` methods `transferTo`, `read(ByteBuffer,long)`, and `write(ByteBuffer,long)` to state "greater than or equal to the file's current size" with respect to the given position instead of "greater than the file's current size."

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

Commit messages:
 - 8029370: (fc) FileChannel javadoc not clear for cases where position == size

Changes: https://git.openjdk.org/jdk/pull/12735/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12735&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8029370
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12735.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12735/head:pull/12735

PR: https://git.openjdk.org/jdk/pull/12735

From bpb at openjdk.org  Thu Feb 23 22:27:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Feb 2023 22:27:05 GMT
Subject: RFR: 8029370: (fc) FileChannel javadoc not clear for cases where
 position == size
In-Reply-To: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
References: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
Message-ID: <I5cyaUdUBcRW-ffSQSM71lGeGzO1s3mtq_ZEAeBNNxQ=.7d5b56dc-4134-4e4b-a3e6-1b95713f9166@github.com>

On Thu, 23 Feb 2023 21:24:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the specifications of the `java.nio.channels.FileChannel` methods `transferTo`, `read(ByteBuffer,long)`, and `write(ByteBuffer,long)` to state "greater than or equal to the file's current size" with respect to the given position instead of "greater than the file's current size."

The modified doc lines in this PR are left unwrapped for reviewing clarity. They can be fixed before integration.

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

PR: https://git.openjdk.org/jdk/pull/12735

From lancea at openjdk.org  Thu Feb 23 23:11:04 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 23 Feb 2023 23:11:04 GMT
Subject: RFR: 8029370: (fc) FileChannel javadoc not clear for cases where
 position == size
In-Reply-To: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
References: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
Message-ID: <TJ00lGWDR4nIGl8y6vIyioRQvUtA9aZqEal652EReEU=.98d9ca44-02ca-4a29-a1f4-71c3f30f2974@github.com>

On Thu, 23 Feb 2023 21:24:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the specifications of the `java.nio.channels.FileChannel` methods `transferTo`, `read(ByteBuffer,long)`, and `write(ByteBuffer,long)` to state "greater than or equal to the file's current size" with respect to the given position instead of "greater than the file's current size."

Hi Brian,

The change looks fine.  

This probably should have a CSR to go with it (unless you have checked on that already)

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12735

From bpb at openjdk.org  Thu Feb 23 23:26:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Feb 2023 23:26:07 GMT
Subject: RFR: 8029370: (fc) FileChannel javadoc not clear for cases where
 position == size
In-Reply-To: <TJ00lGWDR4nIGl8y6vIyioRQvUtA9aZqEal652EReEU=.98d9ca44-02ca-4a29-a1f4-71c3f30f2974@github.com>
References: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
 <TJ00lGWDR4nIGl8y6vIyioRQvUtA9aZqEal652EReEU=.98d9ca44-02ca-4a29-a1f4-71c3f30f2974@github.com>
Message-ID: <1Nnb3DAAiHsQHHvkSkVkKIPkYpFdV5hAy2czqW0jYuw=.c6ba5208-d6ca-46ca-82a1-6ff3d5459b4f@github.com>

On Thu, 23 Feb 2023 23:08:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi Brian,
> 
> The change looks fine.

Thanks, @LanceAndersen .

> This probably should have a CSR to go with it (unless you have checked on that already)

I was on the fence about that. I will check on it.

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

PR: https://git.openjdk.org/jdk/pull/12735

From alanb at openjdk.org  Fri Feb 24 07:00:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 07:00:08 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v5]
In-Reply-To: <W_HuvqiPNipq0E96Q8HUay1iwMrrF2STlKNDYd-D8z0=.0cb78060-fbd1-4070-9397-581c1ba8e5b9@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
 <W_HuvqiPNipq0E96Q8HUay1iwMrrF2STlKNDYd-D8z0=.0cb78060-fbd1-4070-9397-581c1ba8e5b9@github.com>
Message-ID: <9fbd1kEtxdMTCyiOPEYeKUxz2qVQbcd8zIJsjKEi82M=.c43649d6-4e38-4d16-b7d3-58377264aafb@github.com>

On Thu, 23 Feb 2023 21:16:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This enum is not used in the JDK and did not appear in external source code searches.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302806: Remove modifier loops

src/java.base/linux/classes/sun/nio/fs/LinuxWatchService.java line 229:

> 227: 
> 228:             // no modifiers supported at this time
> 229:             if (modifiers != null) {

Suggestion:

            if (modifiers.length > 0) {

Same thing in PollingWatchService.

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

PR: https://git.openjdk.org/jdk/pull/12626

From alanb at openjdk.org  Fri Feb 24 07:56:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 07:56:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <sZ6e3IQf74n8JeZ3jS2RCtNXc3rZVNEhssWPZBF3Syc=.689d0581-f8b8-4d4a-8cbc-bc47868801ba@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Latest version looks good to me, avoids needing stable field or holder class.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12518

From itakiguchi at openjdk.org  Fri Feb 24 08:38:07 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 24 Feb 2023 08:38:07 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Hello @naotoj .
Sorry for bothering you.

I have following question:
- Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
Is there specific reason ?

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

PR: https://git.openjdk.org/jdk/pull/12518

From coffeys at openjdk.org  Fri Feb 24 11:01:08 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 24 Feb 2023 11:01:08 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <gheAf1iB5AFGkfIwBYGfJdW6VvlIc-OGjuCdRQAoyEw=.7f6710eb-8e4a-4376-816a-f16cd1cc8cef@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Marked as reviewed by coffeys (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Fri Feb 24 11:29:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 11:29:03 GMT
Subject: RFR: 8029370: (fc) FileChannel javadoc not clear for cases where
 position == size
In-Reply-To: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
References: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
Message-ID: <1fuq1bWVt4HkoZvBaCnalzQCy0jxj5oOR6YICoXILMk=.55a89707-8ee8-4856-ac5f-419f0b888680@github.com>

On Thu, 23 Feb 2023 21:24:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the specifications of the `java.nio.channels.FileChannel` methods `transferTo`, `read(ByteBuffer,long)`, and `write(ByteBuffer,long)` to state "greater than or equal to the file's current size" with respect to the given position instead of "greater than the file's current size."

Yes, it should be "greater than or equal to the file's current size". I assume transferFrom needs the same change. The javadoc update technically introduces a new testable assertion so I think a CSR should be created.

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

PR: https://git.openjdk.org/jdk/pull/12735

From alanb at openjdk.org  Fri Feb 24 11:40:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 11:40:05 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
Message-ID: <A2XsV6jvLtc5K_RfoEb1yWVRiSu_TJpgpe0Syc4joek=.a2e0741f-6595-4d05-85b8-00ead2e70cc0@github.com>

On Fri, 24 Feb 2023 08:34:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?

That is a good question. It could move, and $PACKAGE replaced with sun.nio.cs, so it would be more obvious from the source location that it is generated into java.base rather than jdk.charsets. Up until now, GB18030 went into java.base on some platforms and jdk.charsets on other platforms. It will be the same for all platforms once this PR is integrated.

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

PR: https://git.openjdk.org/jdk/pull/12518

From bpb at openjdk.org  Fri Feb 24 16:29:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 16:29:04 GMT
Subject: RFR: 8029370: (fc) FileChannel javadoc not clear for cases where
 position == size
In-Reply-To: <1fuq1bWVt4HkoZvBaCnalzQCy0jxj5oOR6YICoXILMk=.55a89707-8ee8-4856-ac5f-419f0b888680@github.com>
References: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
 <1fuq1bWVt4HkoZvBaCnalzQCy0jxj5oOR6YICoXILMk=.55a89707-8ee8-4856-ac5f-419f0b888680@github.com>
Message-ID: <0L1jo_NDMD6a3AO6nXBgQlzvzXIPjDQd9j9GliwcwgM=.daced1cd-372d-4f3f-b340-87086597fc77@github.com>

On Fri, 24 Feb 2023 11:26:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Yes, it should be "greater than or equal to the file's current size". I assume transferFrom needs the same change. The javadoc update technically introduces a new testable assertion so I think a CSR should be created.

I thought I checked `transferFrom` but will look again. A CSR was indeed created.

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

PR: https://git.openjdk.org/jdk/pull/12735

From bpb at openjdk.org  Fri Feb 24 16:35:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 16:35:20 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v6]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <_tucL0gZWMD_bfK_V_jWEunl70NNdP9hH1fxLUrTZ9A=.a928ff9f-7a5d-4482-8ce6-a487f9b03676@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: s/modifiers != null/modifiers.length > 0/

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/20c9ced3..c6e3cf96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From bpb at openjdk.org  Fri Feb 24 16:50:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 16:50:04 GMT
Subject: RFR: 8029370: (fc) FileChannel javadoc not clear for cases where
 position == size
In-Reply-To: <0L1jo_NDMD6a3AO6nXBgQlzvzXIPjDQd9j9GliwcwgM=.daced1cd-372d-4f3f-b340-87086597fc77@github.com>
References: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
 <1fuq1bWVt4HkoZvBaCnalzQCy0jxj5oOR6YICoXILMk=.55a89707-8ee8-4856-ac5f-419f0b888680@github.com>
 <0L1jo_NDMD6a3AO6nXBgQlzvzXIPjDQd9j9GliwcwgM=.daced1cd-372d-4f3f-b340-87086597fc77@github.com>
Message-ID: <_VXxLz3WhRWsbcJSOFKnxfL0g_dYQ6plTUlB1wSM9Ew=.b03d2175-f876-49c3-bf78-141ddaf5aa5d@github.com>

On Fri, 24 Feb 2023 16:25:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I thought I checked `transferFrom` but will look again. A CSR was indeed created.

`transferFrom` does not need `or equal to`:

jshell> FileChannel fc = FileChannel.open(Path.of("junk"), StandardOpenOption.READ, StandardOpenOption.WRITE);
fc ==> sun.nio.ch.FileChannelImpl at 528931cf

jshell> FileChannel fc2 = FileChannel.open(Path.of("junk"), StandardOpenOption.READ, StandardOpenOption.WRITE);
fc2 ==> sun.nio.ch.FileChannelImpl at 1563da5

jshell> fc.size()
$5 ==> 83

jshell> fc.transferFrom(fc2, fc.size(), 8)
$6 ==> 8

jshell> fc.size()
$7 ==> 91

jshell> fc.transferFrom(fc2, fc.size() + 1, 8)
$8 ==> 0

jshell> fc.size()
$9 ==> 91

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

PR: https://git.openjdk.org/jdk/pull/12735

From bpb at openjdk.org  Fri Feb 24 17:14:42 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 17:14:42 GMT
Subject: RFR: 8303083: (bf) Remove private DirectByteBuffer(long,
 int) constructor before JDK 21 GA
Message-ID: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>

Remove the `DirectByteBuffer` constructor what was originally removed by #11873 and subsequently reinstated #12717.

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

Commit messages:
 - 8303083: (bf) Remove private DirectByteBuffer(long, int) constructor before JDK 21 GA

Changes: https://git.openjdk.org/jdk/pull/12745/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12745&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303083
  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12745.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12745/head:pull/12745

PR: https://git.openjdk.org/jdk/pull/12745

From naoto at openjdk.org  Fri Feb 24 17:23:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 17:23:25 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v4]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Failed to add the file itself
 - Changed GB18030 from extcs template to stdcs source

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/4d4015a9..9732e6c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Fri Feb 24 17:23:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 17:23:26 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
Message-ID: <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>

On Fri, 24 Feb 2023 08:34:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> Hello @naotoj . Sorry for bothering you.
> 
> I have following question:
> 
> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>   I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>   Is there specific reason ?

No, there is not. Thanks for pointing it out. Fixed.

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

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Fri Feb 24 17:57:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 17:57:03 GMT
Subject: RFR: 8303083: (bf) Remove private DirectByteBuffer(long,
 int) constructor before JDK 21 GA
In-Reply-To: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>
References: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>
Message-ID: <0ts26yUMMqfHpSQcC-ANOMoBaiY8Lur8bsTl_16Y8V4=.8f7ce0ff-c9fa-4ec4-b215-c72153174325@github.com>

On Fri, 24 Feb 2023 17:06:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the `DirectByteBuffer` constructor what was originally removed by #11873 and subsequently reinstated #12717.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12745

From lancea at openjdk.org  Fri Feb 24 18:13:06 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:13:06 GMT
Subject: RFR: 8303083: (bf) Remove private DirectByteBuffer(long,
 int) constructor before JDK 21 GA
In-Reply-To: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>
References: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>
Message-ID: <ZptW9uv3GpmTvYbxNnQqXKiTFmpY6VTZ7mkCMf1QIHI=.53beb395-05d8-499e-94cd-6e4b0e2d4694@github.com>

On Fri, 24 Feb 2023 17:06:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the `DirectByteBuffer` constructor what was originally removed by #11873 and subsequently reinstated #12717.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12745

From lancea at openjdk.org  Fri Feb 24 18:14:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:14:09 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v4]
In-Reply-To: <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>
Message-ID: <NCWMZuJeSCZIJ64fwTHe2VgNC01TtAaxVGeRj8fh-x4=.8249b760-5221-4dfe-96bc-30672a3934c2@github.com>

On Fri, 24 Feb 2023 17:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Failed to add the file itself
>  - Changed GB18030 from extcs template to stdcs source

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12518

From bpb at openjdk.org  Fri Feb 24 18:33:21 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 18:33:21 GMT
Subject: Withdrawn: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <pV0aTJyoTX3LdJUnK2z0cS4m-__Y_kjWHRHrZuZ8cwM=.8d7fc964-96bc-49ce-abf0-6ed8569e5ea2@github.com>

On Sat, 18 Feb 2023 00:11:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This enum is not used in the JDK and did not appear in external source code searches.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12626

From bpb at openjdk.org  Fri Feb 24 19:02:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 19:02:05 GMT
Subject: RFR: 8303083: (bf) Remove private DirectByteBuffer(long,
 int) constructor before JDK 21 GA
In-Reply-To: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>
References: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>
Message-ID: <RQb8TEs6mqgDUDIUyM5VDjFpi_Mth16F9enCZYPqE4s=.542a60c9-fa56-4768-a8f2-2b7b29501739@github.com>

On Fri, 24 Feb 2023 17:06:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the `DirectByteBuffer` constructor what was originally removed by #11873 and subsequently reinstated #12717.

Top three test tiers pass on all platforms.

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

PR: https://git.openjdk.org/jdk/pull/12745

From bpb at openjdk.org  Fri Feb 24 19:05:18 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 19:05:18 GMT
Subject: Integrated: 8303083: (bf) Remove private DirectByteBuffer(long,
 int) constructor before JDK 21 GA
In-Reply-To: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>
References: <7laoJUu3sQq-L280zRkozBFw4lHqL4MiUyldl5sdseQ=.7d0f5680-88a8-4b2c-8f68-9ee69c2aa31a@github.com>
Message-ID: <QCIklog6-PTLxJqx7JnTZ28AkDf6BB5dmZC5vxR_wfg=.d9a143fe-9b9e-4ce9-ab5b-03b7a4d8ffad@github.com>

On Fri, 24 Feb 2023 17:06:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the `DirectByteBuffer` constructor what was originally removed by #11873 and subsequently reinstated #12717.

This pull request has now been integrated.

Changeset: ccf3340e
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ccf3340e829b1f033bd3e662c7ce782c34f7a89b
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8303083: (bf) Remove private DirectByteBuffer(long, int) constructor before JDK 21 GA

Reviewed-by: alanb, lancea

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

PR: https://git.openjdk.org/jdk/pull/12745

From alanb at openjdk.org  Sat Feb 25 08:38:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 25 Feb 2023 08:38:03 GMT
Subject: RFR: 8029370: (fc) FileChannel javadoc not clear for cases where
 position == size
In-Reply-To: <_VXxLz3WhRWsbcJSOFKnxfL0g_dYQ6plTUlB1wSM9Ew=.b03d2175-f876-49c3-bf78-141ddaf5aa5d@github.com>
References: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
 <1fuq1bWVt4HkoZvBaCnalzQCy0jxj5oOR6YICoXILMk=.55a89707-8ee8-4856-ac5f-419f0b888680@github.com>
 <0L1jo_NDMD6a3AO6nXBgQlzvzXIPjDQd9j9GliwcwgM=.daced1cd-372d-4f3f-b340-87086597fc77@github.com>
 <_VXxLz3WhRWsbcJSOFKnxfL0g_dYQ6plTUlB1wSM9Ew=.b03d2175-f876-49c3-bf78-141ddaf5aa5d@github.com>
Message-ID: <ItAU_bezHKBTJ7k3dOOVxMs0r5PDWF3v-sH89YH6xyQ=.27778985-86bd-4bd7-9ef5-9cf8dc4d069c@github.com>

On Fri, 24 Feb 2023 16:47:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `transferFrom` does not need `or equal to`:

You're right, I forgot thaht transferFrom goes not grow the file like write(src, position), something that might want to re-visited some time.

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

PR: https://git.openjdk.org/jdk/pull/12735

From duke at openjdk.org  Sat Feb 25 12:53:19 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 25 Feb 2023 12:53:19 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v17]
In-Reply-To: <iXUTs9909Egth2l6i-M6yiP4sSSzrRZ7cimnB8FmpWA=.3ada411e-d773-41d3-9c16-2a3c8a49b1bb@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
 <Jh7qxHwulfAXfKht0DbUkNwjd6JHucLHxQnanqngwvQ=.c75f6016-b88c-4c4a-a296-9f28edd14327@github.com>
 <iXUTs9909Egth2l6i-M6yiP4sSSzrRZ7cimnB8FmpWA=.3ada411e-d773-41d3-9c16-2a3c8a49b1bb@github.com>
Message-ID: <1qbp5rnBlN2AYJuDG1pLG944oPraqQSOKhavF-QmhOU=.c911c5fb-2646-4ac5-bf84-6920fb9a61a4@github.com>

On Fri, 17 Feb 2023 16:50:44 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Which platform was used to generate the performance data? Also what was the source stream? Just asking as FileChannel.transferFrom uses copy_file_range for file-to-file (Linux), memory mapping for file-to-file, and a copy loop for other cases.
>> 
>> In any case, the changes to ChannelInputStream.transferTo does the right thing. Most of the change in the PR is the tests. I don't have time to look at those closely right now but Lance or Brian might have cycles.
>
> @AlanBateman @LanceAndersen Kindly asking to resume this MR. Thanks! :-)

> @mkarg: Comments from @LanceAndersen on 2 January 2022:
> > I haven't gone through this in detail, but we want to merge The remaining TransferTo2 tests into TransferTo. For the large File tests, any duplicate code can also be included in the base class.
>
> Unless I missed it somehow, I don't see that this has been addressed. Is there an intent to perform the suggested test merging and duplicate code consolidation?

@bplb I would be happy to continue with merging and removing duplicate code, but I have not yet started this, because @LanceAndersen wrote "I haven't gone through this in detail ... I will look at this more when I am back from the holiday break". So we need to agree *to which extend* we merge both tests (or we need to agree that both files shall become really just one file, as it was originally, before Lance asked to split them). Some background: Originally there was just one file, and it was split into two by request of Lance. So I am not in the position to decide on my own, *which* parts to merge, and *which* parts to keep separated. Can you please give me instructions, which parts you want to keep separated (or confirm that the target really is to just have on single file in the end)? Then I will merge the rest and remove duplicates. Thank you! :-)

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

PR: https://git.openjdk.org/jdk/pull/6711

From duke at openjdk.org  Sat Feb 25 12:53:23 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 25 Feb 2023 12:53:23 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v17]
In-Reply-To: <axdBjQB5JkXmqazIOhvJvqj3g92sN6CzNx-lZOMRDhU=.5d75ddb7-ea49-4515-986d-788dd08437c4@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
 <axdBjQB5JkXmqazIOhvJvqj3g92sN6CzNx-lZOMRDhU=.5d75ddb7-ea49-4515-986d-788dd08437c4@github.com>
Message-ID: <gpzgLLqqFDKjVB1nLQfXGX2sIz5Z5hvqXJFiKivJ9xg=.510d764b-f7f8-4d80-af70-4053d3f30783@github.com>

On Wed, 22 Feb 2023 23:01:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Implementing 8278268
>>   
>>   Signed-off-by: Markus Karg <markus at headcrashing.eu>
>
> test/jdk/java/nio/channels/Channels/TransferTo2.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> The copyright years need to be updated per the usual convention in all files in this PR.

Thanks a lot for this hint! I will do that at thanks. Apparently this happened because the PR was created in 2021 actually.

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

PR: https://git.openjdk.org/jdk/pull/6711

From duke at openjdk.org  Sat Feb 25 13:29:52 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 25 Feb 2023 13:29:52 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v18]
In-Reply-To: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
Message-ID: <zeqPFFObcVGQrMGMWcZfBfFbWf9H_LSskwcQOvD1x9I=.28fb1844-c14e-4b44-a409-711d41f7e595@github.com>

> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6711/files
  - new: https://git.openjdk.org/jdk/pull/6711/files/1965a6c5..4bd0d545

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=6711&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=6711&range=16-17

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/6711.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/6711/head:pull/6711

PR: https://git.openjdk.org/jdk/pull/6711

From duke at openjdk.org  Sat Feb 25 13:29:55 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 25 Feb 2023 13:29:55 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v17]
In-Reply-To: <gpzgLLqqFDKjVB1nLQfXGX2sIz5Z5hvqXJFiKivJ9xg=.510d764b-f7f8-4d80-af70-4053d3f30783@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
 <axdBjQB5JkXmqazIOhvJvqj3g92sN6CzNx-lZOMRDhU=.5d75ddb7-ea49-4515-986d-788dd08437c4@github.com>
 <gpzgLLqqFDKjVB1nLQfXGX2sIz5Z5hvqXJFiKivJ9xg=.510d764b-f7f8-4d80-af70-4053d3f30783@github.com>
Message-ID: <3DhAjQc_d9ku8NG9v-WkxB0GNUc3xVW9ZNdlNSPJOY4=.dcc773a8-7016-4bc4-a708-5f80af240f75@github.com>

On Sat, 25 Feb 2023 12:51:17 GMT, Markus KARG <duke at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Channels/TransferTo2.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>> 
>> The copyright years need to be updated per the usual convention in all files in this PR.
>
> Thanks a lot for this hint! I will do that at thanks. Apparently this happened because the PR was created in 2021 actually.

I have pushed commit https://github.com/openjdk/jdk/pull/6711/commits/4bd0d545414756276dff6d2d4f43167cc451425f which updates the copyright year of all touched files.

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

PR: https://git.openjdk.org/jdk/pull/6711

From itakiguchi at openjdk.org  Sun Feb 26 04:39:17 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sun, 26 Feb 2023 04:39:17 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
 <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>
Message-ID: <7dEDXuB8aO0XFkF9AaUZwP9chbjr5RFzvz1mYZnIx4g=.5ef6ecc2-829e-4c97-a662-4a51768ab994@github.com>

On Fri, 24 Feb 2023 17:19:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> Sorry for bothering you.
>> 
>> I have following question:
>> - Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>> I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>> Is there specific reason ?
>
>> Hello @naotoj . Sorry for bothering you.
>> 
>> I have following question:
>> 
>> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>>   I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>>   Is there specific reason ?
> 
> No, there is not. Thanks for pointing it out. Fixed.

Thanks @naotoj .
That's what I expected.

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

PR: https://git.openjdk.org/jdk/pull/12518

From michaelo at apache.org  Sun Feb 26 20:37:13 2023
From: michaelo at apache.org (Michael Osipov)
Date: Sun, 26 Feb 2023 21:37:13 +0100
Subject: ATOMIC_MOVE fails under high frequency conditions on Windows
Message-ID: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>

Hi folks,

this is Michael from the Apache Maven team.

We have recently released Apache Maven 3.9.0 and shortly after received 
this bug report: https://issues.apache.org/jira/browse/MRESOLVER-325

A short summary of the issue: Maven Resolver 1.9.x uses now same-dir 
temp files with atomic moves to the target to reduce the concurrency 
update window additionally to a high level locking layer. Before release 
we have performed our testing on several POSIX-like platforms like 
Fedora, macOS and FreeBSD, no issue. An Eclipse (Tycho) committer 
approach to us and reported failures now in GH Actions on Windows. The 
failures happen when the same tracking file is updated for the one 
artifact and the same thread (no concurrency), but different classifiers 
(none, sources) within a very short period of time. Windows fails with 
AccessDeniedException. I was able to reproduce it reliably on different 
Windows machines and a standalone example.

Here it is:
> import java.io.IOException;
> import java.io.Writer;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.nio.file.StandardCopyOption;
> 
> public class AtomicMove {
> 
> 	public static void main(String[] args) throws IOException, InterruptedException {
> 
> 		Path target = Paths.get("foo");
> 
> 		for (int i = 0; i < 100; i++) {
> 			Path temp = Paths.get("foo." + i);
> 			try (Writer w = Files.newBufferedWriter(temp)) {
> 				w.write("I was made for crashing you, baby!");
> 			}
> 			Files.move(temp, target, StandardCopyOption.ATOMIC_MOVE);
> 		}
> 	}
> 
> }

fails with:
> Exception in thread "main" java.nio.file.AccessDeniedException: foo.41 -> foo
> 	at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
> 	at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> 	at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301)
> 	at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
> 	at java.nio.file.Files.move(Files.java:1395)
> 	at com.siemens.sb.sso.example.AtomicMove.main(AtomicMove.java:21)

All with Zulu 8+, so 11 and 17 are affected as well since the JDK code 
is identical.

The problem is this piece of code in the JDK:
>         if (atomicMove) {
>             try {
>                 MoveFileEx(sourcePath, targetPath, MOVEFILE_REPLACE_EXISTING);
>             } catch (WindowsException x) {
>                 if (x.lastError() == ERROR_NOT_SAME_DEVICE) {
>                     throw new AtomicMoveNotSupportedException(
>                         source.getPathForExceptionMessage(),
>                         target.getPathForExceptionMessage(),
>                         x.errorString());
>                 }
>                 x.rethrowAsIOException(source, target);
>             }
>             return;
>         }

The MoveFileEx does not properly block until the operation completes and 
some Windows-internal locking fails the operation. Even the
While investigating the problem, it seems to be very common on Windows 
with Jenkins, Kafka, etc. but also Python folks discussed the issue 
(https://github.com/python/cpython/issues/53074).
Now, if I apply the following patch:
> -                Files.move( tempFile, file, StandardCopyOption.ATOMIC_MOVE );
> +                Kernel32.INSTANCE.MoveFileEx( tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
> +                    new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING | WinBase.MOVEFILE_WRITE_THROUGH ) );

It just works. MOVEFILE_WRITE_THROUGH guarantees the operaton to block 
until it is completed.

I know, that Windows does *not* provide atomicity, granted, but it can 
at least block the operation until completion.

Can you guys at least log a bug with JBS and have a look whether you 
could set the flag for plagued Java users on Windows?

For now, we will revert the usage of same-dir temp files with atomic 
moves on those tracking files: 
https://github.com/apache/maven-resolver/pull/259/files

Note: replacing ATOMIC_MOVE with REPLACE_EXISTING yields to another 
exception since the JDK just does DeleteFile() and MoveFileEx() again 
which leads to the same chicken and egg problem.

Many thanks,

Michael

From Alan.Bateman at oracle.com  Mon Feb 27 07:40:06 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Feb 2023 07:40:06 +0000
Subject: ATOMIC_MOVE fails under high frequency conditions on Windows
In-Reply-To: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>
References: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>
Message-ID: <204465d1-a2f7-f0c3-9a1f-f334e0dd9c94@oracle.com>

On 26/02/2023 20:37, Michael Osipov wrote:
>
> The MoveFileEx does not properly block until the operation completes 
> and some Windows-internal locking fails the operation. Even the
> While investigating the problem, it seems to be very common on Windows 
> with Jenkins, Kafka, etc. but also Python folks discussed the issue 
> (https://github.com/python/cpython/issues/53074).
> Now, if I apply the following patch:
>> -??????????????? Files.move( tempFile, file, 
>> StandardCopyOption.ATOMIC_MOVE );
>> +??????????????? Kernel32.INSTANCE.MoveFileEx( 
>> tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
>> +??????????????????? new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING | 
>> WinBase.MOVEFILE_WRITE_THROUGH ) );
>
> It just works. MOVEFILE_WRITE_THROUGH guarantees the operaton to block 
> until it is completed.

Thanks for the bug report, I've created JDK-8303225 [1] to track this. 
On the surface, it seems that the JDK should use MOVEFILE_WRITE_THROUGH 
but it requires working through a bunch of scenarios to see what side 
effects might emerge (just about every change we do on Windows seems to 
have some side effect).

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8303225

From michaelo at apache.org  Mon Feb 27 07:46:10 2023
From: michaelo at apache.org (Michael Osipov)
Date: Mon, 27 Feb 2023 08:46:10 +0100
Subject: ATOMIC_MOVE fails under high frequency conditions on Windows
In-Reply-To: <204465d1-a2f7-f0c3-9a1f-f334e0dd9c94@oracle.com>
References: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>
 <204465d1-a2f7-f0c3-9a1f-f334e0dd9c94@oracle.com>
Message-ID: <151a575c-64ff-9079-0ec2-559bdfb719ba@apache.org>

Am 2023-02-27 um 08:40 schrieb Alan Bateman:
> On 26/02/2023 20:37, Michael Osipov wrote:
>>
>> The MoveFileEx does not properly block until the operation completes 
>> and some Windows-internal locking fails the operation. Even the
>> While investigating the problem, it seems to be very common on Windows 
>> with Jenkins, Kafka, etc. but also Python folks discussed the issue 
>> (https://github.com/python/cpython/issues/53074).
>> Now, if I apply the following patch:
>>> -??????????????? Files.move( tempFile, file, 
>>> StandardCopyOption.ATOMIC_MOVE );
>>> +??????????????? Kernel32.INSTANCE.MoveFileEx( 
>>> tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
>>> +??????????????????? new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING | 
>>> WinBase.MOVEFILE_WRITE_THROUGH ) );
>>
>> It just works. MOVEFILE_WRITE_THROUGH guarantees the operaton to block 
>> until it is completed.
> 
> Thanks for the bug report, I've created JDK-8303225 [1] to track this. 
> On the surface, it seems that the JDK should use MOVEFILE_WRITE_THROUGH 
> but it requires working through a bunch of scenarios to see what side 
> effects might emerge (just about every change we do on Windows seems to 
> have some side effect).
> 
> -Alan
> 
> [1] https://bugs.openjdk.org/browse/JDK-8303225


Thanks Alan!

Please update the issue for "Affects Version" with 8 and 17 as well.

Regards,

Michael

From naoto at openjdk.org  Mon Feb 27 16:39:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Feb 2023 16:39:25 GMT
Subject: Integrated: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <qgQlYhYos9HSO_KWfSk8FPX1pxdfch9VwquZcrsxiSc=.f6660687-b56d-464c-9e7b-5c349df3b46e@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

This pull request has now been integrated.

Changeset: a253b460
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a253b4602147633a3d2e83775d1feef4f12a5272
Stats:     273 lines in 14 files changed: 117 ins; 41 del; 115 mod

8301119: Support for GB18030-2022

Reviewed-by: alanb, coffeys, lancea

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

PR: https://git.openjdk.org/jdk/pull/12518

From rcmuir at gmail.com  Mon Feb 27 16:56:57 2023
From: rcmuir at gmail.com (Robert Muir)
Date: Mon, 27 Feb 2023 11:56:57 -0500
Subject: ATOMIC_MOVE fails under high frequency conditions on Windows
In-Reply-To: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>
References: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>
Message-ID: <CAOdYfZU7ZDr9sSO3y1jFCRWrYLeqzkeBxZ-0HBNyKihpgfq-9A@mail.gmail.com>

On Sun, Feb 26, 2023 at 3:37?PM Michael Osipov <michaelo at apache.org> wrote:
> The MoveFileEx does not properly block until the operation completes and
> some Windows-internal locking fails the operation. Even the
> While investigating the problem, it seems to be very common on Windows
> with Jenkins, Kafka, etc. but also Python folks discussed the issue
> (https://github.com/python/cpython/issues/53074).
> Now, if I apply the following patch:
> > -                Files.move( tempFile, file, StandardCopyOption.ATOMIC_MOVE );
> > +                Kernel32.INSTANCE.MoveFileEx( tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
> > +                    new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING | WinBase.MOVEFILE_WRITE_THROUGH ) );
>
> It just works. MOVEFILE_WRITE_THROUGH guarantees the operaton to block
> until it is completed.

Hi, we rely on this as well in apache lucene, and have some gnarly
tests around it, but we haven't seen this specific issue.
Maybe we dodge it because we always fsync() files before renaming
them? I don't see any synchronization to disk in your sample code. It
could be a possible workaround for your problem, and generally IMO
should be done anyway rather than relying upon hacks like
auto_da_alloc to do it for us:
https://docs.kernel.org/admin-guide/ext4.html

From uschindler at apache.org  Mon Feb 27 17:02:36 2023
From: uschindler at apache.org (Uwe Schindler)
Date: Mon, 27 Feb 2023 18:02:36 +0100
Subject: ATOMIC_MOVE fails under high frequency conditions on Windows
In-Reply-To: <CAOdYfZU7ZDr9sSO3y1jFCRWrYLeqzkeBxZ-0HBNyKihpgfq-9A@mail.gmail.com>
References: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>
 <CAOdYfZU7ZDr9sSO3y1jFCRWrYLeqzkeBxZ-0HBNyKihpgfq-9A@mail.gmail.com>
Message-ID: <a1c35de3-9c03-e941-b468-50622f5ce0fe@apache.org>

I also added a comment to the Maven issue: 
https://issues.apache.org/jira/browse/MRESOLVER-325?focusedCommentId=17694090&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17694090

In fact, for correct transactional behaviour you should fsync the file 
before renaming. The delayed rename is caused by the fact that Windows 
sees still sees dirty blocks.

But I agree that atomic-move in Java should *additionally* be 
implemented to not be async and only return whan all is done.

Uwe

Am 27.02.2023 um 17:56 schrieb Robert Muir:
> On Sun, Feb 26, 2023 at 3:37?PM Michael Osipov <michaelo at apache.org> wrote:
>> The MoveFileEx does not properly block until the operation completes and
>> some Windows-internal locking fails the operation. Even the
>> While investigating the problem, it seems to be very common on Windows
>> with Jenkins, Kafka, etc. but also Python folks discussed the issue
>> (https://github.com/python/cpython/issues/53074).
>> Now, if I apply the following patch:
>>> -                Files.move( tempFile, file, StandardCopyOption.ATOMIC_MOVE );
>>> +                Kernel32.INSTANCE.MoveFileEx( tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
>>> +                    new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING | WinBase.MOVEFILE_WRITE_THROUGH ) );
>> It just works. MOVEFILE_WRITE_THROUGH guarantees the operaton to block
>> until it is completed.
> Hi, we rely on this as well in apache lucene, and have some gnarly
> tests around it, but we haven't seen this specific issue.
> Maybe we dodge it because we always fsync() files before renaming
> them? I don't see any synchronization to disk in your sample code. It
> could be a possible workaround for your problem, and generally IMO
> should be done anyway rather than relying upon hacks like
> auto_da_alloc to do it for us:
> https://docs.kernel.org/admin-guide/ext4.html

-- 
Uwe Schindler
uschindler at apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/


From bpb at openjdk.org  Mon Feb 27 17:15:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Feb 2023 17:15:19 GMT
Subject: Integrated: 8029370: (fc) FileChannel javadoc not clear for cases
 where position == size
In-Reply-To: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
References: <DUNeIROg8X6EcDMCJo4YSm4ZdofYUOs0JyeUFf4BkHs=.9914d995-507f-4e7c-9854-2a6de0d87ec0@github.com>
Message-ID: <ph7n1GQA41GEkusxoWv0wRZVw6iGnCZ70dPmieu5gzE=.b7b9eab2-0a78-4047-9910-a9fe6d46b1ea@github.com>

On Thu, 23 Feb 2023 21:24:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the specifications of the `java.nio.channels.FileChannel` methods `transferTo`, `read(ByteBuffer,long)`, and `write(ByteBuffer,long)` to state "greater than or equal to the file's current size" with respect to the given position instead of "greater than the file's current size."

This pull request has now been integrated.

Changeset: 42330d28
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42330d28da28da034da1927302990f458e76cad1
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8029370: (fc) FileChannel javadoc not clear for cases where position == size

Reviewed-by: lancea

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

PR: https://git.openjdk.org/jdk/pull/12735

From bpb at openjdk.org  Tue Feb 28 21:26:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Feb 2023 21:26:15 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v17]
In-Reply-To: <3DhAjQc_d9ku8NG9v-WkxB0GNUc3xVW9ZNdlNSPJOY4=.dcc773a8-7016-4bc4-a708-5f80af240f75@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com>
 <axdBjQB5JkXmqazIOhvJvqj3g92sN6CzNx-lZOMRDhU=.5d75ddb7-ea49-4515-986d-788dd08437c4@github.com>
 <gpzgLLqqFDKjVB1nLQfXGX2sIz5Z5hvqXJFiKivJ9xg=.510d764b-f7f8-4d80-af70-4053d3f30783@github.com>
 <3DhAjQc_d9ku8NG9v-WkxB0GNUc3xVW9ZNdlNSPJOY4=.dcc773a8-7016-4bc4-a708-5f80af240f75@github.com>
Message-ID: <K6WqQcIW86gAgFRUaboBLKRM63YbKlvfkr6rpy_vrHM=.a0af2e31-0d54-4540-9730-881a34278e21@github.com>

On Sat, 25 Feb 2023 13:25:01 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Thanks a lot for this hint! I will do that at thanks. Apparently this happened because the PR was created in 2021 actually.
>
> I have pushed commit https://github.com/openjdk/jdk/pull/6711/commits/4bd0d545414756276dff6d2d4f43167cc451425f which updates the copyright year of all touched files.

Looks correct now.

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

PR: https://git.openjdk.org/jdk/pull/6711

From bpb at openjdk.org  Tue Feb 28 23:53:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Feb 2023 23:53:14 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v18]
In-Reply-To: <zeqPFFObcVGQrMGMWcZfBfFbWf9H_LSskwcQOvD1x9I=.28fb1844-c14e-4b44-a409-711d41f7e595@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <zeqPFFObcVGQrMGMWcZfBfFbWf9H_LSskwcQOvD1x9I=.28fb1844-c14e-4b44-a409-711d41f7e595@github.com>
Message-ID: <iZi7DBs0uY5MJSH0N1quXHnuQ2aWxhf3icpcFNET9Uc=.4135cc6e-057b-4cc1-9ab0-73d46c5b2de6@github.com>

On Sat, 25 Feb 2023 13:29:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright

Before anything else, you might consider merging the current master into your branch. Aside from the copyright year change of the most recent commit, the branch is over two and a half months out of date.

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

PR: https://git.openjdk.org/jdk/pull/6711