From duke at openjdk.org  Mon Oct  2 12:47:14 2023
From: duke at openjdk.org (David Voit)
Date: Mon, 2 Oct 2023 12:47:14 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
Message-ID: <nYsvaPhlNkaILHLYBnAY0-JUAjEpqA6S1VYuqPRH6g4=.6007befe-7fff-430a-9ea5-711a8b3e2bbe@github.com>

On Fri, 29 Sep 2023 16:35:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
> 
>  - Wrap copy_statx_attributes with ifdef __linux__
>  - Fix compile warnings.
>  - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 212:

> 210: 
> 211: #if defined(_DARWIN_FEATURE_64_BIT_INODE) || defined(__linux__)
> 212: static jfieldID attrs_st_birthtime_sec;

birthtime_nsec missing? Just set it to zero on darwin and use the value under linux?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1341667257

From sgehwolf at openjdk.org  Mon Oct  2 12:47:17 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Oct 2023 12:47:17 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <nxBzWO5wEjuUfhxJ7Yj_j9Om2yqWzl0CLJB5h-D-ryQ=.d8ac9760-f6b7-404b-b6d7-dc834dc0647f@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
 <nxBzWO5wEjuUfhxJ7Yj_j9Om2yqWzl0CLJB5h-D-ryQ=.d8ac9760-f6b7-404b-b6d7-dc834dc0647f@github.com>
Message-ID: <pKhyTypjbV1Pd5Egf2BaStPstnwkxX6qlsazuk3YHMU=.eb7861c8-972c-4302-b552-af209477fc6a@github.com>

On Fri, 29 Sep 2023 17:27:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
>> 
>>  - Wrap copy_statx_attributes with ifdef __linux__
>>  - Fix compile warnings.
>>  - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34:
> 
>> 32:  */
>> 33: 
>> 34: import java.lang.reflect.Method;
> 
> Instead of using reflective access, would it be possible to use the "os.version" property and a minimum kernel version (4.11?)?
> 
> 
> jshell> System.getProperty("os.version")
> $1 ==> "5.19.0-50-generic"
> 
> jshell> 
> bpb at bpb-vb-u2204:~$ uname -a
> Linux bpb-vb-u2204 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux```

It's not the full story. On an alpine build, on `5.19.0-50` it would report the wrong value. It's not supported, since the libc impl doesn't support it. The kernel itself would as a regular, non-alpine build, attests. I could use `!Platform.isMusl()` in addition if that sounds OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1342638406

From sgehwolf at openjdk.org  Mon Oct  2 13:11:17 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Oct 2023 13:11:17 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <nYsvaPhlNkaILHLYBnAY0-JUAjEpqA6S1VYuqPRH6g4=.6007befe-7fff-430a-9ea5-711a8b3e2bbe@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
 <nYsvaPhlNkaILHLYBnAY0-JUAjEpqA6S1VYuqPRH6g4=.6007befe-7fff-430a-9ea5-711a8b3e2bbe@github.com>
Message-ID: <tpUNzfy13GEnhaIR5oDxfr-VieeEgYWh8DhPCM6yWEk=.1bba94fc-8e85-449b-953b-36cd6b9ddbc2@github.com>

On Fri, 29 Sep 2023 18:07:49 GMT, David Voit <duke at openjdk.org> wrote:

>> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
>> 
>>  - Wrap copy_statx_attributes with ifdef __linux__
>>  - Fix compile warnings.
>>  - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux
>
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 212:
> 
>> 210: 
>> 211: #if defined(_DARWIN_FEATURE_64_BIT_INODE) || defined(__linux__)
>> 212: static jfieldID attrs_st_birthtime_sec;
> 
> birthtime_nsec missing? Just set it to zero on darwin and use the value under linux?

I've deliberately omitted that change here, not sure if this change of behaviour is wanted as it would add a field in `UnixFileAttributes` (it was part of the v2 patch). @bplb @AlanBateman Thoughts? I can include it of course, but don't want to go in circles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1342671545

From sgehwolf at openjdk.org  Mon Oct  2 13:15:18 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Oct 2023 13:15:18 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <nxBzWO5wEjuUfhxJ7Yj_j9Om2yqWzl0CLJB5h-D-ryQ=.d8ac9760-f6b7-404b-b6d7-dc834dc0647f@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
 <nxBzWO5wEjuUfhxJ7Yj_j9Om2yqWzl0CLJB5h-D-ryQ=.d8ac9760-f6b7-404b-b6d7-dc834dc0647f@github.com>
Message-ID: <5W2DUmdAB-ww-w76g6G9LCL9aWAeu8ENartgA1_WfG0=.b2fbf964-eaf4-4405-b51a-50693462a764@github.com>

On Fri, 29 Sep 2023 17:27:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
>> 
>>  - Wrap copy_statx_attributes with ifdef __linux__
>>  - Fix compile warnings.
>>  - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34:
> 
>> 32:  */
>> 33: 
>> 34: import java.lang.reflect.Method;
> 
> Instead of using reflective access, would it be possible to use the "os.version" property and a minimum kernel version (4.11?)?
> 
> 
> jshell> System.getProperty("os.version")
> $1 ==> "5.19.0-50-generic"
> 
> jshell> 
> bpb at bpb-vb-u2204:~$ uname -a
> Linux bpb-vb-u2204 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux```

Hmm, @bplb `Platform.isMusl()` doesn't seem to work reliably. Running an alpine binary on Linux (Fedora) in my case, breaks this test as it gets `Platform.isMusl() == false`. Also, there is a chance where the JDK runs on an old glibc (<2.28) and new enough kernel, where this wouldn't work either. Using the reflective approach seems most consistent with what the code is actually doing. More thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1342677367

From sgehwolf at openjdk.org  Mon Oct  2 13:21:18 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Oct 2023 13:21:18 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v4]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <w5iqDDSLjK_5rRUcrq1JoH3OpLmAEjL3EeizOis5yAo=.eb52afdf-352e-4758-a989-22d159a85ae3@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

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

  Fix style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/070c413a..7aa251b6

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

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

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

From jvernee at openjdk.org  Mon Oct  2 16:07:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 2 Oct 2023 16:07:09 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v33]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

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

  Remove PIP annotation from jdk.incubator.vector

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/17dacbbd..cc89a519

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=31-32

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

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

From duke at openjdk.org  Mon Oct  2 18:06:36 2023
From: duke at openjdk.org (David Voit)
Date: Mon, 2 Oct 2023 18:06:36 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <tpUNzfy13GEnhaIR5oDxfr-VieeEgYWh8DhPCM6yWEk=.1bba94fc-8e85-449b-953b-36cd6b9ddbc2@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
 <nYsvaPhlNkaILHLYBnAY0-JUAjEpqA6S1VYuqPRH6g4=.6007befe-7fff-430a-9ea5-711a8b3e2bbe@github.com>
 <tpUNzfy13GEnhaIR5oDxfr-VieeEgYWh8DhPCM6yWEk=.1bba94fc-8e85-449b-953b-36cd6b9ddbc2@github.com>
Message-ID: <JZuZVoQ-g_PlhKuWrXJWkN1r-gzj_3hNGCeIFl87sgw=.4a9aed26-c0bc-4c67-bcc5-4ef21197a5b6@github.com>

On Mon, 2 Oct 2023 13:07:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 212:
>> 
>>> 210: 
>>> 211: #if defined(_DARWIN_FEATURE_64_BIT_INODE) || defined(__linux__)
>>> 212: static jfieldID attrs_st_birthtime_sec;
>> 
>> birthtime_nsec missing? Just set it to zero on darwin and use the value under linux?
>
> I've deliberately omitted that change here, not sure if this change of behaviour is wanted as it would add a field in `UnixFileAttributes` (it was part of the v2 patch). @bplb @AlanBateman Thoughts? I can include it of course, but don't want to go in circles.

Understood, seems just a little bit silly that a limitation in a different kernel (darwin) artificially limits the birthtime here, while it easily accessible with statx. Otherwise this patch series looks quite good!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1342996360

From bpb at openjdk.org  Mon Oct  2 18:51:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Oct 2023 18:51:02 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException [v2]
In-Reply-To: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
Message-ID: <Mn2hBxxftzgMqWm04Wbaifqz7wY0uQcVTG8UEFtGlpw=.b4f82f44-0417-456b-bfca-231c3d0c3a35@github.com>

> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.

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

  8317128: Remove replaceExistingOrEmpty method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15991/files
  - new: https://git.openjdk.org/jdk/pull/15991/files/365149c7..4a34ff3b

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

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

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

From bpb at openjdk.org  Mon Oct  2 18:51:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Oct 2023 18:51:05 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException [v2]
In-Reply-To: <5ar7nVuS0bVkQh4kZVvY7Tx1AcBCiAuawllebwsyZYY=.2848d320-d2dc-4433-863b-bcfd9120ea21@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
 <5ar7nVuS0bVkQh4kZVvY7Tx1AcBCiAuawllebwsyZYY=.2848d320-d2dc-4433-863b-bcfd9120ea21@github.com>
Message-ID: <sMJOwhA9vOWSDEAsc-7ieCH1PHLWvfLUSiWXsZZQts0=.9faa458f-342c-463f-a698-e8f9d32ebbf7@github.com>

On Sat, 30 Sep 2023 06:24:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8317128: Remove replaceExistingOrEmpty method
>
> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 150:
> 
>> 148:             Files.createDirectory(target);
>> 149:         } else {
>> 150:             try (InputStream in = Files.newInputStream(source)) {
> 
> If we are you reverting that then I assume you also should revert the change to L147 too, meaning replaceExistingOrEmpty() isn't needed now.

`replaceExistingOrEmpty()` removed in 4a34ff3b36bbcbd43139f7888ac4d953ecef91da.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15991#discussion_r1343030243

From alanb at openjdk.org  Mon Oct  2 19:46:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Oct 2023 19:46:22 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException [v2]
In-Reply-To: <Mn2hBxxftzgMqWm04Wbaifqz7wY0uQcVTG8UEFtGlpw=.b4f82f44-0417-456b-bfca-231c3d0c3a35@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
 <Mn2hBxxftzgMqWm04Wbaifqz7wY0uQcVTG8UEFtGlpw=.b4f82f44-0417-456b-bfca-231c3d0c3a35@github.com>
Message-ID: <7Sj_4_El-A_SdU8g7r8GzavYrT0MfiRZDJ2GRKXU5MU=.136fa309-2e3c-4dfa-9a78-347eedac3c4f@github.com>

On Mon, 2 Oct 2023 18:51:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317128: Remove replaceExistingOrEmpty method

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15991#pullrequestreview-1653381715

From sgehwolf at openjdk.org  Tue Oct  3 10:02:32 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 10:02:32 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

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

  Add support for nano seconds for btime on Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/7aa251b6..643251db

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

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

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

From sgehwolf at openjdk.org  Tue Oct  3 10:05:25 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 10:05:25 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <JZuZVoQ-g_PlhKuWrXJWkN1r-gzj_3hNGCeIFl87sgw=.4a9aed26-c0bc-4c67-bcc5-4ef21197a5b6@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
 <nYsvaPhlNkaILHLYBnAY0-JUAjEpqA6S1VYuqPRH6g4=.6007befe-7fff-430a-9ea5-711a8b3e2bbe@github.com>
 <tpUNzfy13GEnhaIR5oDxfr-VieeEgYWh8DhPCM6yWEk=.1bba94fc-8e85-449b-953b-36cd6b9ddbc2@github.com>
 <JZuZVoQ-g_PlhKuWrXJWkN1r-gzj_3hNGCeIFl87sgw=.4a9aed26-c0bc-4c67-bcc5-4ef21197a5b6@github.com>
Message-ID: <KFf9RT3ebQqVX9XVj4ZqseYhIwH8VB59OowVvdeIF1k=.d951228c-ccc1-4d00-ac03-40b5aa04b3f4@github.com>

On Mon, 2 Oct 2023 18:03:33 GMT, David Voit <duke at openjdk.org> wrote:

>> I've deliberately omitted that change here, not sure if this change of behaviour is wanted as it would add a field in `UnixFileAttributes` (it was part of the v2 patch). @bplb @AlanBateman Thoughts? I can include it of course, but don't want to go in circles.
>
> Understood, seems just a little bit silly that a limitation in a different kernel (darwin) artificially limits the birthtime here, while it easily accessible with statx. Otherwise this patch series looks quite good!

Well, I've reconsidered. It's fairly trivial to support, so I've added it. The latest patch does this. It's an incremental webrev change so we can go back if not desired.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343843993

From sgehwolf at openjdk.org  Tue Oct  3 10:05:27 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 10:05:27 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <5W2DUmdAB-ww-w76g6G9LCL9aWAeu8ENartgA1_WfG0=.b2fbf964-eaf4-4405-b51a-50693462a764@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
 <nxBzWO5wEjuUfhxJ7Yj_j9Om2yqWzl0CLJB5h-D-ryQ=.d8ac9760-f6b7-404b-b6d7-dc834dc0647f@github.com>
 <5W2DUmdAB-ww-w76g6G9LCL9aWAeu8ENartgA1_WfG0=.b2fbf964-eaf4-4405-b51a-50693462a764@github.com>
Message-ID: <UP0WbBgAT3gIraG8J8becSl2VQjijKLHNSTn3168rV0=.ce733192-f6c5-4879-aea6-46694d1a8e9a@github.com>

On Mon, 2 Oct 2023 13:12:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34:
>> 
>>> 32:  */
>>> 33: 
>>> 34: import java.lang.reflect.Method;
>> 
>> Instead of using reflective access, would it be possible to use the "os.version" property and a minimum kernel version (4.11?)?
>> 
>> 
>> jshell> System.getProperty("os.version")
>> $1 ==> "5.19.0-50-generic"
>> 
>> jshell> 
>> bpb at bpb-vb-u2204:~$ uname -a
>> Linux bpb-vb-u2204 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux```
>
> Hmm, @bplb `Platform.isMusl()` doesn't seem to work reliably. Running an alpine binary on Linux (Fedora) in my case, breaks this test as it gets `Platform.isMusl() == false`. Also, there is a chance where the JDK runs on an old glibc (<2.28) and new enough kernel, where this wouldn't work either. Using the reflective approach seems most consistent with what the code is actually doing. More thoughts?

For now I'd like to keep the reflective approach until we know a better way to determine support correctly otherwise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343845097

From alanb at openjdk.org  Tue Oct  3 10:14:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Oct 2023 10:14:19 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
Message-ID: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>

On Tue, 3 Oct 2023 10:02:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for nano seconds for btime on Linux

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 28:

> 26: package sun.nio.fs;
> 27: 
> 28: import java.nio.file.attribute.BasicFileAttributes;

I assume you'll update the copyright date on this file.

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 706:

> 704: #if defined(__linux__)
> 705:     }
> 706: #endif

Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read. There are several places where we'll need to fix the indent with nested ifdef usage as it's hard to ready right now.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 140:

> 138:             return (boolean)supportsBirthTime.invoke(null);
> 139:         } catch (Throwable e) {
> 140:             throw new RuntimeException("Illegal state!");

I agree with Brian, we need to find a better way to do this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343854783
PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343857110
PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343857459

From alanb at openjdk.org  Tue Oct  3 10:18:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Oct 2023 10:18:37 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
Message-ID: <XK0KaKHsiTp9a9EAtv2LRzGOgSkZ2SEnHKTmVyOT4ho=.f7f69a7e-0561-46fe-a2f0-c657adc51a8b@github.com>

On Tue, 3 Oct 2023 10:02:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for nano seconds for btime on Linux

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 350:

> 348: #if defined (__linux__) // Linux has nsec granularity
> 349:     attrs_st_birthtime_nsec = (*env)->GetFieldID(env, clazz, "st_birthtime_nsec", "J");
> 350:     CHECK_NULL_RETURN(attrs_st_birthtime_sec, 0);

This should check attrs_st_birthtime_nsec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343863736

From sgehwolf at openjdk.org  Tue Oct  3 11:39:37 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 11:39:37 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
 <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
Message-ID: <d2O_6vULmnyd-mwq02SHjCnly1Sjji58zRTd1ogRdHM=.84a85e62-2a8e-44ba-a101-25049b39b2a8@github.com>

On Tue, 3 Oct 2023 10:09:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for nano seconds for btime on Linux
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 28:
> 
>> 26: package sun.nio.fs;
>> 27: 
>> 28: import java.nio.file.attribute.BasicFileAttributes;
> 
> I assume you'll update the copyright date on this file.

OK.

> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 140:
> 
>> 138:             return (boolean)supportsBirthTime.invoke(null);
>> 139:         } catch (Throwable e) {
>> 140:             throw new RuntimeException("Illegal state!");
> 
> I agree with Brian, we need to find a better way to do this.

Sure, happy to. Any suggestions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343956701
PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343955999

From sgehwolf at openjdk.org  Tue Oct  3 11:47:43 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 11:47:43 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
 <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
Message-ID: <sxCZPHdgvNzurJ-4dnaTRf1eT6L0SMnfI0r4QLllQww=.84d6b5d5-789b-4fab-bf10-351b15c239fe@github.com>

On Tue, 3 Oct 2023 10:11:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read.

I'm not sure I follow. We need the `statx` code *and* the old `stat64` code on Linux as that's the fall-back code when `statx` isn't supported. We don't need the `statx` code on other platforms. If I used `#if defined(__linux__) ... #else ... #endif` instead, I wouldn't get the stat64 code on Linux without duplication. What am I missing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343966374

From sgehwolf at openjdk.org  Tue Oct  3 11:59:13 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 11:59:13 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v6]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <yl-zUTJzNm7Cgq7SE0o1Q-GAw3JsncGmBHCxBKZK3lk=.142d050c-6a28-443a-a036-69c86ecfc271@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision:

 - Fix indents
 - Check correct fieldID
 - Add copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/643251db..5149545d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=04-05

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

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

From sgehwolf at openjdk.org  Tue Oct  3 11:59:13 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 11:59:13 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <sxCZPHdgvNzurJ-4dnaTRf1eT6L0SMnfI0r4QLllQww=.84d6b5d5-789b-4fab-bf10-351b15c239fe@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
 <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
 <sxCZPHdgvNzurJ-4dnaTRf1eT6L0SMnfI0r4QLllQww=.84d6b5d5-789b-4fab-bf10-351b15c239fe@github.com>
Message-ID: <jIPzCQ9xLsuLQ2LGuNSRyEvYmaypIg7l9thQa_EYmxk=.a8f94669-3376-47df-813d-cd46bf363208@github.com>

On Tue, 3 Oct 2023 11:43:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 706:
>> 
>>> 704: #if defined(__linux__)
>>> 705:     }
>>> 706: #endif
>> 
>> Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read. There are several places where we'll need to fix the indent with nested ifdef usage as it's hard to ready right now.
>
>> Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read.
> 
> I'm not sure I follow. We need the `statx` code *and* the old `stat64` code on Linux as that's the fall-back code when `statx` isn't supported. We don't need the `statx` code on other platforms. If I used `#if defined(__linux__) ... #else ... #endif` instead, I wouldn't get the stat64 code on Linux without duplication. What am I missing?

I've added indents. Not sure if it's any better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343978722

From alanb at openjdk.org  Tue Oct  3 12:05:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Oct 2023 12:05:36 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <jIPzCQ9xLsuLQ2LGuNSRyEvYmaypIg7l9thQa_EYmxk=.a8f94669-3376-47df-813d-cd46bf363208@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
 <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
 <sxCZPHdgvNzurJ-4dnaTRf1eT6L0SMnfI0r4QLllQww=.84d6b5d5-789b-4fab-bf10-351b15c239fe@github.com>
 <jIPzCQ9xLsuLQ2LGuNSRyEvYmaypIg7l9thQa_EYmxk=.a8f94669-3376-47df-813d-cd46bf363208@github.com>
Message-ID: <xJKryDJQN1vZjkbDLuQAfh9J5oKUESkGCbfQ_CmLISg=.b9ed9587-40dc-4714-b863-7c98a6757c7d@github.com>

On Tue, 3 Oct 2023 11:54:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read.
>> 
>> I'm not sure I follow. We need the `statx` code *and* the old `stat64` code on Linux as that's the fall-back code when `statx` isn't supported. We don't need the `statx` code on other platforms. If I used `#if defined(__linux__) ... #else ... #endif` instead, I wouldn't get the stat64 code on Linux without duplication. What am I missing?
>
> I've added indents. Not sure if it's any better.

>  What am I missing?

If you remove the "} else {" then it will be a lot simpler. The thing that I don't like is the `#if defined(__linux__) } #endif` at the end of each function, we shouldn't need that and the code will be a lot easier to read if the "} else {" is removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343987930

From sgehwolf at openjdk.org  Tue Oct  3 12:37:35 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 12:37:35 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <xJKryDJQN1vZjkbDLuQAfh9J5oKUESkGCbfQ_CmLISg=.b9ed9587-40dc-4714-b863-7c98a6757c7d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
 <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
 <sxCZPHdgvNzurJ-4dnaTRf1eT6L0SMnfI0r4QLllQww=.84d6b5d5-789b-4fab-bf10-351b15c239fe@github.com>
 <jIPzCQ9xLsuLQ2LGuNSRyEvYmaypIg7l9thQa_EYmxk=.a8f94669-3376-47df-813d-cd46bf363208@github.com>
 <xJKryDJQN1vZjkbDLuQAfh9J5oKUESkGCbfQ_CmLISg=.b9ed9587-40dc-4714-b863-7c98a6757c7d@github.com>
Message-ID: <3znWaDuChhRyt0U-9_hPo8wSmkfTZlhUvVuJCy1Y4ho=.66c7e041-d6ce-4ecc-9ea0-8645c71a605b@github.com>

On Tue, 3 Oct 2023 12:02:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I've added indents. Not sure if it's any better.
>
>>  What am I missing?
> 
> If you remove the "} else {" then it will be a lot simpler. The thing that I don't like is the `#if defined(__linux__) } #endif` at the end of each function, we shouldn't need that and the code will be a lot easier to read if the "} else {" is removed.

OK, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344025907

From sgehwolf at openjdk.org  Tue Oct  3 12:37:38 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 12:37:38 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <d2O_6vULmnyd-mwq02SHjCnly1Sjji58zRTd1ogRdHM=.84a85e62-2a8e-44ba-a101-25049b39b2a8@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
 <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
 <d2O_6vULmnyd-mwq02SHjCnly1Sjji58zRTd1ogRdHM=.84a85e62-2a8e-44ba-a101-25049b39b2a8@github.com>
Message-ID: <JSRIUdD9NFfTJO0__Ycl-Qlc2aIiHdfZiilvN1RFIJA=.0caff140-584e-45fc-9c4d-854cac351939@github.com>

On Tue, 3 Oct 2023 11:35:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 140:
>> 
>>> 138:             return (boolean)supportsBirthTime.invoke(null);
>>> 139:         } catch (Throwable e) {
>>> 140:             throw new RuntimeException("Illegal state!");
>> 
>> I agree with Brian, we need to find a better way to do this.
>
> Sure, happy to. Any suggestions?

I'm experimenting with a native function in a test helper. Hopefully that'll be more amenable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344027014

From sgehwolf at openjdk.org  Tue Oct  3 13:07:21 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 13:07:21 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v7]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <ey1zaxmu7w4CxP5sv_LhCr6lTWwYVDHbEnJYwadGvZc=.40b3e618-9ad9-4810-a877-c603a9ba76be@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:

 - Cleanup UnixNativeDispatcher.c
 - Refactor test so as to not use reflection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/5149545d..3b30596d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=05-06

  Stats: 159 lines in 4 files changed: 99 ins; 58 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792

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

From sgehwolf at openjdk.org  Tue Oct  3 13:07:23 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 13:07:23 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <3znWaDuChhRyt0U-9_hPo8wSmkfTZlhUvVuJCy1Y4ho=.66c7e041-d6ce-4ecc-9ea0-8645c71a605b@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
 <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
 <sxCZPHdgvNzurJ-4dnaTRf1eT6L0SMnfI0r4QLllQww=.84d6b5d5-789b-4fab-bf10-351b15c239fe@github.com>
 <jIPzCQ9xLsuLQ2LGuNSRyEvYmaypIg7l9thQa_EYmxk=.a8f94669-3376-47df-813d-cd46bf363208@github.com>
 <xJKryDJQN1vZjkbDLuQAfh9J5oKUESkGCbfQ_CmLISg=.b9ed9587-40dc-4714-b863-7c98a6757c7d@github.com>
 <3znWaDuChhRyt0U-9_hPo8wSmkfTZlhUvVuJCy1Y4ho=.66c7e041-d6ce-4ecc-9ea0-8645c71a605b@github.com>
Message-ID: <OPyUlymTqp_iVU9qcA5DzGA7fWfs-ocZlmpjchWIn80=.145b2930-cb0b-4120-8f69-31bb88eff8a7@github.com>

On Tue, 3 Oct 2023 12:33:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>>  What am I missing?
>> 
>> If you remove the "} else {" then it will be a lot simpler. The thing that I don't like is the `#if defined(__linux__) } #endif` at the end of each function, we shouldn't need that and the code will be a lot easier to read if the "} else {" is removed.
>
> OK, thanks.

Should be fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344067971

From sgehwolf at openjdk.org  Tue Oct  3 13:07:25 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 13:07:25 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v5]
In-Reply-To: <JSRIUdD9NFfTJO0__Ycl-Qlc2aIiHdfZiilvN1RFIJA=.0caff140-584e-45fc-9c4d-854cac351939@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wxzabnnCx2CTAOv6p_dZpISZvNMID9_hxiUb1x6K90M=.b5ea40c9-df1b-41ed-b499-9eb741c2e12d@github.com>
 <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com>
 <d2O_6vULmnyd-mwq02SHjCnly1Sjji58zRTd1ogRdHM=.84a85e62-2a8e-44ba-a101-25049b39b2a8@github.com>
 <JSRIUdD9NFfTJO0__Ycl-Qlc2aIiHdfZiilvN1RFIJA=.0caff140-584e-45fc-9c4d-854cac351939@github.com>
Message-ID: <8fIPHLIWaXOXEzVH-JglIuSmWxd5Zz1Z2Q1lcXSXdBY=.a58645fe-2801-4db3-bc80-a2383639de9c@github.com>

On Tue, 3 Oct 2023 12:34:22 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sure, happy to. Any suggestions?
>
> I'm experimenting with a native function in a test helper. Hopefully that'll be more amenable.

That's what's being used in the latest version now. No more reflection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344067657

From sgehwolf at openjdk.org  Tue Oct  3 17:41:24 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Oct 2023 17:41:24 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v8]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Link libCreationTimeHelper with -ldl
 - Merge branch 'master' into JDK-8316304-statx-create-time-new
 - Cleanup UnixNativeDispatcher.c
 - Refactor test so as to not use reflection
 - Fix indents
 - Check correct fieldID
 - Add copyright
 - Add support for nano seconds for btime on Linux
 - Fix style
 - Wrap copy_statx_attributes with ifdef __linux__
 - ... and 2 more: https://git.openjdk.org/jdk/compare/590d707b...83347ec1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/3b30596d..83347ec1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=06-07

  Stats: 80501 lines in 2327 files changed: 31105 ins; 14997 del; 34399 mod
  Patch: https://git.openjdk.org/jdk/pull/15792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792

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

From bpb at openjdk.org  Tue Oct  3 18:10:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Oct 2023 18:10:56 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v8]
In-Reply-To: <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
Message-ID: <bWnDiIoHQMx5CZaShJ1AoQOGDXYm75EsSn_PZBLXlok=.6bbd8fae-4be6-4e78-985d-f30219187d90@github.com>

On Tue, 3 Oct 2023 17:41:24 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Link libCreationTimeHelper with -ldl
>  - Merge branch 'master' into JDK-8316304-statx-create-time-new
>  - Cleanup UnixNativeDispatcher.c
>  - Refactor test so as to not use reflection
>  - Fix indents
>  - Check correct fieldID
>  - Add copyright
>  - Add support for nano seconds for btime on Linux
>  - Fix style
>  - Wrap copy_statx_attributes with ifdef __linux__
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/65113b79...83347ec1

test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 33:

> 31: {
> 32: #if defined(__linux__)
> 33:     void* statx_func = dlsym(RTLD_DEFAULT, "statx");

For commit 04226fd470bc9a238e83606cb7f62ebd64d44421, which is the penultimate commit, I am seeing the build error:


open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:33: error: undefined reference to 'dlsym'```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344525162

From bpb at openjdk.org  Wed Oct  4 00:15:01 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Oct 2023 00:15:01 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v8]
In-Reply-To: <bWnDiIoHQMx5CZaShJ1AoQOGDXYm75EsSn_PZBLXlok=.6bbd8fae-4be6-4e78-985d-f30219187d90@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
 <bWnDiIoHQMx5CZaShJ1AoQOGDXYm75EsSn_PZBLXlok=.6bbd8fae-4be6-4e78-985d-f30219187d90@github.com>
Message-ID: <x6GXN_KzNbiMbIDMzJ90F9BjUFwWdTyGMEwnExTCDpw=.316c3d51-45ba-4fd6-8396-4244925a3a03@github.com>

On Tue, 3 Oct 2023 18:08:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Link libCreationTimeHelper with -ldl
>>  - Merge branch 'master' into JDK-8316304-statx-create-time-new
>>  - Cleanup UnixNativeDispatcher.c
>>  - Refactor test so as to not use reflection
>>  - Fix indents
>>  - Check correct fieldID
>>  - Add copyright
>>  - Add support for nano seconds for btime on Linux
>>  - Fix style
>>  - Wrap copy_statx_attributes with ifdef __linux__
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/6e6821d7...83347ec1
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 33:
> 
>> 31: {
>> 32: #if defined(__linux__)
>> 33:     void* statx_func = dlsym(RTLD_DEFAULT, "statx");
> 
> For commit 04226fd470bc9a238e83606cb7f62ebd64d44421, which is the penultimate commit, I am seeing the build error:
> 
> 
> open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:33: error: undefined reference to 'dlsym'```

The above build failure is fixed in commit 83347ec1c9fee2a859470fff8e391c5f6970d226.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344900913

From sgehwolf at openjdk.org  Wed Oct  4 08:16:40 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Oct 2023 08:16:40 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v8]
In-Reply-To: <x6GXN_KzNbiMbIDMzJ90F9BjUFwWdTyGMEwnExTCDpw=.316c3d51-45ba-4fd6-8396-4244925a3a03@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
 <bWnDiIoHQMx5CZaShJ1AoQOGDXYm75EsSn_PZBLXlok=.6bbd8fae-4be6-4e78-985d-f30219187d90@github.com>
 <x6GXN_KzNbiMbIDMzJ90F9BjUFwWdTyGMEwnExTCDpw=.316c3d51-45ba-4fd6-8396-4244925a3a03@github.com>
Message-ID: <WnCXfKshiK4EqdkDsNsZj6VCPWMeeOo58YKWzalfshI=.a5fb38db-0557-4f98-9149-cdeca1d884cb@github.com>

On Wed, 4 Oct 2023 00:12:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 33:
>> 
>>> 31: {
>>> 32: #if defined(__linux__)
>>> 33:     void* statx_func = dlsym(RTLD_DEFAULT, "statx");
>> 
>> For commit 04226fd470bc9a238e83606cb7f62ebd64d44421, which is the penultimate commit, I am seeing the build error:
>> 
>> 
>> open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:33: error: undefined reference to 'dlsym'```
>
> The above build failure is fixed in commit 83347ec1c9fee2a859470fff8e391c5f6970d226.

Yes, sorry about that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1345388943

From sgehwolf at openjdk.org  Wed Oct  4 10:06:40 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Oct 2023 10:06:40 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v8]
In-Reply-To: <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
Message-ID: <2rRIBH3ENt-bNRuJXRof5WXlJpaDR59eGdCw2xut6Y8=.9ab76c02-49f9-48a0-8031-ec4059b528c8@github.com>

On Tue, 3 Oct 2023 17:41:24 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Link libCreationTimeHelper with -ldl
>  - Merge branch 'master' into JDK-8316304-statx-create-time-new
>  - Cleanup UnixNativeDispatcher.c
>  - Refactor test so as to not use reflection
>  - Fix indents
>  - Check correct fieldID
>  - Add copyright
>  - Add support for nano seconds for btime on Linux
>  - Fix style
>  - Wrap copy_statx_attributes with ifdef __linux__
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/d9b097ab...83347ec1

x86 (32 bit) GHA failure seems unrelated. My testing seems OK for this patch. Feel free to run your own.

Please let me know if there is anything else that still needs to be addressed.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1746548920

From stuefe at openjdk.org  Wed Oct  4 12:40:43 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 4 Oct 2023 12:40:43 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v8]
In-Reply-To: <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
Message-ID: <5nDIXc3OLGBrTawxGQnmeHTiajj0LeS_hhCOGLOHR6A=.af6116fe-5eaf-43af-b9fd-2c894f5effc3@github.com>

On Tue, 3 Oct 2023 17:41:24 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Link libCreationTimeHelper with -ldl
>  - Merge branch 'master' into JDK-8316304-statx-create-time-new
>  - Cleanup UnixNativeDispatcher.c
>  - Refactor test so as to not use reflection
>  - Fix indents
>  - Check correct fieldID
>  - Add copyright
>  - Add support for nano seconds for btime on Linux
>  - Fix style
>  - Wrap copy_statx_attributes with ifdef __linux__
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/ca543a9a...83347ec1

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 80:

> 78: // support. We still want to ensure we can call statx at runtime
> 79: // if the runtime glibc version supports it (>= 2.28)
> 80: #ifndef __NR_statx

As long as we have to accommodate the case where struct statx is not defined, we may just as well do it always: just define a structure binary compatible to statx but named differently (e.g. my_statx) to prevent name clashes in case the structure happens to be defined already from libc; then use that structure as return type for your function pointer.

The advantage would be you don't need to know and depend on __NR_statx, and you don't need to include asm/unistd. And no two cases to build and test.

We do this already in other places, see e.g. the dynamic inclusion of mallinfo2() in os_linux.cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1345719922

From sgehwolf at openjdk.org  Wed Oct  4 13:24:44 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Oct 2023 13:24:44 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v8]
In-Reply-To: <5nDIXc3OLGBrTawxGQnmeHTiajj0LeS_hhCOGLOHR6A=.af6116fe-5eaf-43af-b9fd-2c894f5effc3@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
 <5nDIXc3OLGBrTawxGQnmeHTiajj0LeS_hhCOGLOHR6A=.af6116fe-5eaf-43af-b9fd-2c894f5effc3@github.com>
Message-ID: <nJ7DVpBzY3iu2Gn6uFWKzBMHFzFsu2lAP_NqyEGIbpo=.35808ff0-d85d-42a2-8c60-a40665673355@github.com>

On Wed, 4 Oct 2023 12:31:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Link libCreationTimeHelper with -ldl
>>  - Merge branch 'master' into JDK-8316304-statx-create-time-new
>>  - Cleanup UnixNativeDispatcher.c
>>  - Refactor test so as to not use reflection
>>  - Fix indents
>>  - Check correct fieldID
>>  - Add copyright
>>  - Add support for nano seconds for btime on Linux
>>  - Fix style
>>  - Wrap copy_statx_attributes with ifdef __linux__
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b213660e...83347ec1
>
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 80:
> 
>> 78: // support. We still want to ensure we can call statx at runtime
>> 79: // if the runtime glibc version supports it (>= 2.28)
>> 80: #ifndef __NR_statx
> 
> As long as we have to accommodate the case where struct statx is not defined, we may just as well do it always: just define a structure binary compatible to statx but named differently (e.g. my_statx) to prevent name clashes in case the structure happens to be defined already from libc; then use that structure as return type for your function pointer.
> 
> The advantage would be you don't need to know and depend on __NR_statx, and you don't need to include asm/unistd. And no two cases to build and test.
> 
> We do this already in other places, see e.g. the dynamic inclusion of mallinfo2() in os_linux.cpp.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1345789779

From sgehwolf at openjdk.org  Wed Oct  4 16:10:38 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Oct 2023 16:10:38 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v9]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <AH01VphSS7iV5orsePfAXStAXFJL7Z9MhI3jtzy2t30=.f4b86d2d-e9f0-4f65-bd70-6d7c751f791b@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

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

  Use custom but compatible statx struct always

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/83347ec1..a196c822

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=07-08

  Stats: 22 lines in 1 file changed: 1 ins; 6 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/15792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792

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

From sgehwolf at openjdk.org  Wed Oct  4 16:11:23 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Oct 2023 16:11:23 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v8]
In-Reply-To: <nJ7DVpBzY3iu2Gn6uFWKzBMHFzFsu2lAP_NqyEGIbpo=.35808ff0-d85d-42a2-8c60-a40665673355@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <j7ulLky48S3k-B5PuOU0Qypv3esS5BNa55jKthbHlwQ=.6a1c007b-92a6-4fc5-b1a7-069727cfc780@github.com>
 <5nDIXc3OLGBrTawxGQnmeHTiajj0LeS_hhCOGLOHR6A=.af6116fe-5eaf-43af-b9fd-2c894f5effc3@github.com>
 <nJ7DVpBzY3iu2Gn6uFWKzBMHFzFsu2lAP_NqyEGIbpo=.35808ff0-d85d-42a2-8c60-a40665673355@github.com>
Message-ID: <8fiFrrNfDNq5sUhuYT2puOm7Z3C8H2XPSWkCcOh6xMg=.250d4230-3267-49d7-93c1-3c4191053bf4@github.com>

On Wed, 4 Oct 2023 13:21:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 80:
>> 
>>> 78: // support. We still want to ensure we can call statx at runtime
>>> 79: // if the runtime glibc version supports it (>= 2.28)
>>> 80: #ifndef __NR_statx
>> 
>> As long as we have to accommodate the case where struct statx is not defined, we may just as well do it always: just define a structure binary compatible to statx but named differently (e.g. my_statx) to prevent name clashes in case the structure happens to be defined already from libc; then use that structure as return type for your function pointer.
>> 
>> The advantage would be you don't need to know and depend on __NR_statx, and you don't need to include asm/unistd. And no two cases to build and test.
>> 
>> We do this already in other places, see e.g. the dynamic inclusion of mallinfo2() in os_linux.cpp.
>
> OK.

Should be done now in the latest patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1345930010

From stuefe at openjdk.org  Wed Oct  4 17:18:47 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 4 Oct 2023 17:18:47 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v9]
In-Reply-To: <AH01VphSS7iV5orsePfAXStAXFJL7Z9MhI3jtzy2t30=.f4b86d2d-e9f0-4f65-bd70-6d7c751f791b@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <AH01VphSS7iV5orsePfAXStAXFJL7Z9MhI3jtzy2t30=.f4b86d2d-e9f0-4f65-bd70-6d7c751f791b@github.com>
Message-ID: <tO4mtwULz1QeFx0JoAlVDCB0LxWrCe2bcuwFMrp_5Ho=.d9ff4334-d031-4180-8f2c-98d14eaaf028@github.com>

On Wed, 4 Oct 2023 16:10:38 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use custom but compatible statx struct always

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 722:

> 720:         }
> 721:     }
> 722: #endif

Are you missing a return here or did you really intent to call both  `statx` and `lstat64` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1346212918

From sgehwolf at openjdk.org  Wed Oct  4 19:00:54 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Oct 2023 19:00:54 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v9]
In-Reply-To: <tO4mtwULz1QeFx0JoAlVDCB0LxWrCe2bcuwFMrp_5Ho=.d9ff4334-d031-4180-8f2c-98d14eaaf028@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <AH01VphSS7iV5orsePfAXStAXFJL7Z9MhI3jtzy2t30=.f4b86d2d-e9f0-4f65-bd70-6d7c751f791b@github.com>
 <tO4mtwULz1QeFx0JoAlVDCB0LxWrCe2bcuwFMrp_5Ho=.d9ff4334-d031-4180-8f2c-98d14eaaf028@github.com>
Message-ID: <khWiJGwnGBltUArWK6rKn9D_k9CajXA2biiaVcAYER4=.842bbc38-be7b-49a7-b463-de3d740d73e3@github.com>

On Wed, 4 Oct 2023 17:15:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use custom but compatible statx struct always
>
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 722:
> 
>> 720:         }
>> 721:     }
>> 722: #endif
> 
> Are you missing a return here or did you really intent to call both  `statx` and `lstat64` ?

Good catch! The original code had this in `if () ... else ...` blocks. Will fix. It needs to get fixed elsewhere too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1346326389

From sgehwolf at openjdk.org  Wed Oct  4 19:15:01 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Oct 2023 19:15:01 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

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

  Add missing returns when statx is available

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/a196c822..ad428030

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=08-09

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

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

From bpb at openjdk.org  Wed Oct  4 23:38:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Oct 2023 23:38:43 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException [v3]
In-Reply-To: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
Message-ID: <c_s2L3dZpAzWBkAov0KzinMhBY81x8LwhuOSKiZ1ULY=.2f59e336-77e1-4c0f-a3c0-01507704a036@github.com>

> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.

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

  8317128: Add different provider read access check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15991/files
  - new: https://git.openjdk.org/jdk/pull/15991/files/4a34ff3b..299ffa51

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

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

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

From stuefe at openjdk.org  Thu Oct  5 06:00:19 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Oct 2023 06:00:19 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
Message-ID: <mp6SFK-wkPy94Wky9dFo--gCNVOhtcd6slJDx5JUdzI=.6fcc1753-f87e-4fde-8cd2-462a1fd86511@github.com>

On Wed, 4 Oct 2023 19:15:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing returns when statx is available

Looks good to me now, but Brian or Alan should okay this too.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1658926831

From sgehwolf at openjdk.org  Thu Oct  5 08:13:22 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 5 Oct 2023 08:13:22 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <mp6SFK-wkPy94Wky9dFo--gCNVOhtcd6slJDx5JUdzI=.6fcc1753-f87e-4fde-8cd2-462a1fd86511@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
 <mp6SFK-wkPy94Wky9dFo--gCNVOhtcd6slJDx5JUdzI=.6fcc1753-f87e-4fde-8cd2-462a1fd86511@github.com>
Message-ID: <CV9wg6zNFpwOGArBnGpwIP9lao-E-4CfAPlHm2myTlM=.78719127-48c2-4f6d-ba6d-86c543307e5c@github.com>

On Thu, 5 Oct 2023 05:57:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Looks good to me now, but Brian or Alan should okay this too.

Yes, sure. Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1748339213

From bpb at openjdk.org  Thu Oct  5 14:55:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Oct 2023 14:55:08 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <CV9wg6zNFpwOGArBnGpwIP9lao-E-4CfAPlHm2myTlM=.78719127-48c2-4f6d-ba6d-86c543307e5c@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
 <mp6SFK-wkPy94Wky9dFo--gCNVOhtcd6slJDx5JUdzI=.6fcc1753-f87e-4fde-8cd2-462a1fd86511@github.com>
 <CV9wg6zNFpwOGArBnGpwIP9lao-E-4CfAPlHm2myTlM=.78719127-48c2-4f6d-ba6d-86c543307e5c@github.com>
Message-ID: <_Z5HaH-Iwh9pcwunD3juODPS--31k5wy6UKFaImX9xs=.8cc253fe-1cdd-4fda-87ff-0c953205424d@github.com>

On Thu, 5 Oct 2023 08:10:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Looks good to me now, but Brian or Alan should okay this too.

@AlanBateman is away this week so I would expect this review to continue into next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1749048096

From mbaesken at openjdk.org  Thu Oct  5 15:21:54 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Oct 2023 15:21:54 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages
Message-ID: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>

On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
This leads sometimes to exceptions like

MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]

see https://bugs.openjdk.org/browse/JDK-8317307

It would be better to have a message explaining the reason instead of "no further information" .

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

Commit messages:
 - JDK-8317603

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

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

From djelinski at openjdk.org  Thu Oct  5 16:16:28 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 5 Oct 2023 16:16:28 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <NqbcFJs2aNgANSImLpaEBJixXKp0y16nGgOnsf6B6YM=.c334dbd3-2e3e-4ac4-881a-21fcba779242@github.com>

On Thu, 5 Oct 2023 14:33:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

src/java.base/windows/native/libnio/ch/Net.c line 1:

> 1: /*

Thanks for this, the "no further information" message wasn't pretty.
I'm not a fan of mixing styles, and this file uses `NET_ThrowNew` a lot. Can we choose either `NET_ThrowNew` or `handleSocketErrorMessage` and use in consistently everywhere?
Also, the `NET_ThrowNew` messages usually list the function name only, without the `failed` suffix. Can we strip that suffix here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1347674947

From bpb at openjdk.org  Thu Oct  5 20:18:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Oct 2023 20:18:44 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException [v4]
In-Reply-To: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
Message-ID: <SCJUh5GBufJybA5GNTYIAxT5f0fa2JbyNZSlhBx4Q_Y=.9f409226-8bc7-44c8-8ca1-4bc885972478@github.com>

> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.

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

  8317128: Move read check outside replaceExisting c conditional

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15991/files
  - new: https://git.openjdk.org/jdk/pull/15991/files/299ffa51..e6028854

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

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

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

From lancea at openjdk.org  Thu Oct  5 20:32:01 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 5 Oct 2023 20:32:01 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException [v4]
In-Reply-To: <SCJUh5GBufJybA5GNTYIAxT5f0fa2JbyNZSlhBx4Q_Y=.9f409226-8bc7-44c8-8ca1-4bc885972478@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
 <SCJUh5GBufJybA5GNTYIAxT5f0fa2JbyNZSlhBx4Q_Y=.9f409226-8bc7-44c8-8ca1-4bc885972478@github.com>
Message-ID: <K0VlFlguoOvG5I8O5Z2jPPrFlC4lLa-_lJqhxcOKXgw=.1e730d02-845f-43ff-9574-61ae8afd372b@github.com>

On Thu, 5 Oct 2023 20:18:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317128: Move read check outside replaceExisting c conditional

looks Ok to me

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15991#pullrequestreview-1660654539

From alanb at openjdk.org  Fri Oct  6 05:46:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Oct 2023 05:46:01 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException [v4]
In-Reply-To: <SCJUh5GBufJybA5GNTYIAxT5f0fa2JbyNZSlhBx4Q_Y=.9f409226-8bc7-44c8-8ca1-4bc885972478@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
 <SCJUh5GBufJybA5GNTYIAxT5f0fa2JbyNZSlhBx4Q_Y=.9f409226-8bc7-44c8-8ca1-4bc885972478@github.com>
Message-ID: <Otd-MjDicAFmXz6bQFn-xg9xYPcI-vF2rH2xENowmbI=.7faee253-b85a-4225-bed9-0bc266feca95@github.com>

On Thu, 5 Oct 2023 20:18:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317128: Move read check outside replaceExisting c conditional

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15991#pullrequestreview-1661148538

From mbaesken at openjdk.org  Fri Oct  6 07:21:13 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Oct 2023 07:21:13 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v2]
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com>

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

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

  switch to NET_ThrowNew

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16057/files
  - new: https://git.openjdk.org/jdk/pull/16057/files/949309f7..70fb7f16

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

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

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

From mbaesken at openjdk.org  Fri Oct  6 07:21:14 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Oct 2023 07:21:14 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <PkNHs3TdlWtcYEV7YXoI_pwxI2dAKnOTdER-Cy87oyk=.ad7e8c14-a8e3-4662-a92a-f1ec8e9334d8@github.com>

On Thu, 5 Oct 2023 14:33:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

Hi Daniel, thanks for looking into it. I switched my calls to NET_ThrowNew and removed the 'failed' suffix of the message.

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1750096508

From vtewari at openjdk.org  Fri Oct  6 09:46:00 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 6 Oct 2023 09:46:00 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v2]
In-Reply-To: <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com>
Message-ID: <i34pV8_1EVeyhpBt843lfUu3vaYmj2E-M4nYELb5vVA=.6f26e04c-046f-4621-94e2-7c7f4476bbb0@github.com>

On Fri, 6 Oct 2023 07:21:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch to NET_ThrowNew

src/java.base/windows/native/libnio/ch/Net.c line 589:

> 587:     n = getsockopt(fdval(env, fdo), IPPROTO_IP, IP_MULTICAST_IF, (void*)&in, &arglen);
> 588:     if (n == SOCKET_ERROR) {
> 589:         NET_ThrowNew(env, WSAGetLastError(), "setsockopt");

there is typo, third argument should be "getsockopt"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1348460558

From djelinski at openjdk.org  Fri Oct  6 09:46:00 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 6 Oct 2023 09:46:00 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v2]
In-Reply-To: <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com>
Message-ID: <IY_JJ9tO3grTYpCdrkyBaLCLfSBzajPo4RmzCDmwCvE=.0b1f06e0-0da3-4550-9284-a0f1a64ddcf1@github.com>

On Fri, 6 Oct 2023 07:21:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch to NET_ThrowNew

src/java.base/windows/native/libnio/ch/Net.c line 732:

> 730:             }
> 731:         } else if (optError != NO_ERROR) {
> 732:             NET_ThrowNew(env, optError, "getsockopt");

This is not a `getsockopt` error, and using `"getsockopt"` here will make errors thrown here indistinguishable from errors thrown a few lines above. Can we use a different text?
The errors here will usually be the result of async connect, but I'm not sure if that's guaranteed; `SO_ERROR` would probably be the safest choice, but it doesn't look pretty. I guess that's one of the places where "no further information" actually makes sense.
Other than this, LGTM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1348390145

From mbaesken at openjdk.org  Fri Oct  6 11:08:13 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Oct 2023 11:08:13 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v3]
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

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

  adjust message texts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16057/files
  - new: https://git.openjdk.org/jdk/pull/16057/files/70fb7f16..c3b7e85d

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

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

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

From mbaesken at openjdk.org  Fri Oct  6 11:08:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Oct 2023 11:08:15 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v2]
In-Reply-To: <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com>
Message-ID: <H8lNyK6I41LCwfKNqRDFIAB7TwGA0eCJXFoO897hIRo=.8243b7bf-ce11-44b5-bf15-caa9257f5ea3@github.com>

On Fri, 6 Oct 2023 07:21:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch to NET_ThrowNew

Thanks, I adjusted the 2 messages mentioned .

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1750303763

From vtewari at openjdk.org  Fri Oct  6 11:36:07 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 6 Oct 2023 11:36:07 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v3]
In-Reply-To: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
Message-ID: <MUmo9eQchN1eAqOxegKA0Gh8gYKZbpkU4W3x-CKhmxI=.dd834b3e-b75c-4232-a9ac-b82c68192c90@github.com>

On Fri, 6 Oct 2023 11:08:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust message texts

Looks OK to me.

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16057#pullrequestreview-1661674427

From mbaesken at openjdk.org  Fri Oct  6 13:39:45 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Oct 2023 13:39:45 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v3]
In-Reply-To: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
Message-ID: <O4oS5o9GtxgzV0CdwldyLdnY7PsE-hpego0agHcefuA=.d9d17fdb-3a04-4982-a660-afe1905d9475@github.com>

On Fri, 6 Oct 2023 11:08:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust message texts

Thanks for the review !
Daniel , are you okay with the latest version ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1750695930

From alanb at openjdk.org  Fri Oct  6 13:59:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Oct 2023 13:59:40 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v3]
In-Reply-To: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
Message-ID: <yg2fw_2MG2ey9kPT5WIQIksWmwrMXizeV7XmtCdw0po=.c564c1cf-a6a2-463c-b9e3-ca1ab5fad258@github.com>

On Fri, 6 Oct 2023 11:08:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust message texts

I plan to review this as I think we'll need to do a few other changes as part of this.

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1750724507

From jvernee at openjdk.org  Fri Oct  6 16:12:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 6 Oct 2023 16:12:57 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v34]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <NsxvXlXyhw8HGMrXEIi3DxWPLo4VGwrKdWuWNQrVldU=.e25c725d-64d3-4167-ba03-f9838e03ccd8@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:

 - fix failing RestrictedMethods test
 - Merge branch 'master' into JEP22
 - Remove PIP annotation from jdk.incubator.vector
 - review @enablePreview from java/foreign/TestRestricted test
 - Merge branch 'master' into JEP22
 - drop unneeded @compile tags from jtreg tests
 - Use IAE instead of UOE for unsupported char sets
 - Use abort instead of IEA when encountering wrong value for ENA attrib.
 - Fix visibility issues
   
   Reviewed-by: mcimadamore
 - Review comments
 - ... and 53 more: https://git.openjdk.org/jdk/compare/b3cc0c84...b4a7b7ab

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=33
  Stats: 4361 lines in 263 files changed: 2211 ins; 1196 del; 954 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

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

From jvernee at openjdk.org  Fri Oct  6 16:13:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 6 Oct 2023 16:13:33 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v33]
In-Reply-To: <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com>
Message-ID: <AXCC_-1No5nfLP2vvLdZHQDD10rnjCuvAuAiGBk073Q=.73d4833b-b413-4ab6-b3ef-4cd447aee8e3@github.com>

On Mon, 2 Oct 2023 16:07:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
>> 
>> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
>> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
>> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
>> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
>> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
>> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
>> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
>> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
>> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove PIP annotation from jdk.incubator.vector

I've addressed one more test failure in [b4a7b7a](https://github.com/openjdk/jdk/pull/15103/commits/b4a7b7abe75aee72c8e56c12c0ddbeb597e15f1b) that was found after merging this patch with the most recent master branch.

The test in questions checks for linter warnings for restricted methods. It depends on the FFM API for that, which is still preview in the master branch, but no longer preview as part of this patch. Hence the warnings the compiler outputs is different, and the test fails. I've fixed to test. The preview flags are no longer needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1751015355

From bpb at openjdk.org  Fri Oct  6 17:49:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 6 Oct 2023 17:49:30 GMT
Subject: Integrated: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException
In-Reply-To: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
Message-ID: <Mv_fHv07kT3rehmC2XnsYl9qs8CktsAGJ24nJkkLnxc=.a20e6461-58cf-4fbf-bc63-9bb37448a845@github.com>

On Fri, 29 Sep 2023 15:57:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.

This pull request has now been integrated.

Changeset: 6c6beba2
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c6beba2569a2f9f3fd5d6988360ffd8680de821
Stats:     29 lines in 2 files changed: 15 ins; 11 del; 3 mod

8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException

Reviewed-by: alanb, lancea

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

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

From bpb at openjdk.org  Fri Oct  6 21:49:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 6 Oct 2023 21:49:31 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView(posix)
 incorrectly returns 'true' for FAT32 volume on macOS
Message-ID: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>

Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32.

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

Commit messages:
 - 8317687: (fs) FileStore.supportsFileAttributeView(posix) incorrectly returns 'true' for FAT32 volume on macOS

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

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

From bpb at openjdk.org  Fri Oct  6 21:49:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 6 Oct 2023 21:49:31 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView(posix)
 incorrectly returns 'true' for FAT32 volume on macOS
In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
Message-ID: <Mn6Tg_B6CsuX4hFvv6pKZgxhzswE3Oruqq3hpgYjnMc=.9d3d6690-deb1-4707-b921-6ea589d213e3@github.com>

On Fri, 6 Oct 2023 21:39:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32.

This change also exposed a problem in the `java/nio/file/Files/CopyAndMove.java` test which failed in `CopyAndMove.checkBasicAttributes` due to the source and destination last modified time stamps not being equal. This was due to FAT32 volumes having only a resolution of 2 seconds for the write time. The test is incidentally modified to allow an offset of no more than 2 seconds in this case.

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

PR Comment: https://git.openjdk.org/jdk/pull/16084#issuecomment-1751434290

From alanb at openjdk.org  Sat Oct  7 06:25:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Oct 2023 06:25:56 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS
In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
Message-ID: <FebecvVbTrLqiOg81I0foEh1MKPkgMSu3iLKmktZaFE=.cdf3f255-5b50-4ddf-9c08-df3c440a5702@github.com>

On Fri, 6 Oct 2023 21:39:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32.

src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 107:

> 105:         if (type == PosixFileAttributeView.class &&
> 106:             entry().fstype().equals("msdos"))
> 107:             return false;

I suspect supportsFileAttributeView(String) will need to be changed to return false if the view name is "unix".

test/jdk/java/nio/file/Files/CopyAndMove.java line 158:

> 156:                                   attrs1.fileKey(), attrs1.lastModifiedTime());
> 157:                 System.err.format("File time for %s is %s\n",
> 158:                                   attrs2.fileKey(), attrs2.lastModifiedTime());

Are you 150% sure this is reliable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1349471509
PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1349471986

From alanb at openjdk.org  Sat Oct  7 12:47:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Oct 2023 12:47:06 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v3]
In-Reply-To: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
Message-ID: <ExV4fJML9zE_Bwi64PL4zUMi0xJ8H7riJzCjiVJpfCs=.a56f5840-5b43-49cd-b1ec-ab65a5ee1279@github.com>

On Fri, 6 Oct 2023 11:08:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust message texts

Moving to using NET_ThrowNew is okay but it creates inconsistencies that have to be fixed. I think this PR will go through a few iterations.

Some background here is that the socket code no longer exists in libnet/net.dll and at some point we need to do some cleanup and refactoring so that libnio does not have libnet as a dependency (if you go through the JBS issue you'll see a number of startup/first-use issues caused by this dependency). We don't have to do this as part of this PR of course but it provides some context.

For this PR, the issue with changing the specific functions to use NET_ThrowNet is that handleSocketError is left in place for DatagramChannelImpl.c, IOUtil.c and UnixDomainSocket.c. We shouldn't do that. We either replace usages (and remove handleSocketError) or change the existing function to take an additional message.

src/java.base/windows/native/libnio/ch/Net.c line 559:

> 557:     int n = setGroupSourceReqOption(env, fdo, opt, group, index, source);
> 558:     if (n == SOCKET_ERROR) {
> 559:         NET_ThrowNew(env, WSAGetLastError(), "setsockopt with group source request");

That message looks odd, I think you want "setsocketopt to block or unblock source".

src/java.base/windows/native/libnio/ch/Net.c line 638:

> 636:     int count = 0;
> 637:     if (NET_SocketAvailable(fdval(env, fdo), &count) != 0) {
> 638:         NET_ThrowNew(env, WSAGetLastError(), "socket availability check");

This should be "ioctlsocket", not ""socket availability check". Better still would be to just replace the usage of NET_SocketAvailable to use ioctlsocket directly as we will eventually remove NET_SocketAvailable.

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1751703045
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1349516548
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1349516493

From alanb at openjdk.org  Sat Oct  7 13:01:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Oct 2023 13:01:16 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
Message-ID: <UK67ODZ6NVLWfT_sVCP33BRmfw5iZ9NNOpSK7EZWOMg=.e3aeb90a-672e-46c1-843f-c18b766f77f2@github.com>

On Wed, 4 Oct 2023 19:15:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing returns when statx is available

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96:

> 94:             System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead);
> 95:             // Creation time updates are not supported on Linux
> 96:             supportsCreationTimeWrite = false;

It might be simpler to use `Linker.nativeLinker().defaultLookup().find("statx").isPresent()` as that would avoid adding CreationTimeHelper. JEP 454 is proposed to target 22 so the test won't need @enablePreview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1349518168

From alanb at openjdk.org  Sat Oct  7 13:13:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Oct 2023 13:13:17 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
Message-ID: <3yg6BZX9C1esvVPAFmGt60AykzyDj7PQeZ27weyyOTE=.bd37a111-0a6c-462a-b92c-4aa40363d02f@github.com>

On Wed, 4 Oct 2023 19:15:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing returns when statx is available

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 281:

> 279:                          int follow_symlink) {
> 280:     if (follow_symlink == NO_FOLLOW_SYMLINK) {
> 281:       flags |= AT_SYMLINK_NOFOLLOW;

I think it would be better if statx_wrapper had the same signature as statx. Have you tried adding the AT_SYMLINK_NOFOLLOW flag at the use-site?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1349519444

From alanb at openjdk.org  Sat Oct  7 13:16:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Oct 2023 13:16:07 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
Message-ID: <G59ZVZaz-wsjonzubBSAk-CafiPAzkYIxbuhDfbCi3U=.b2c1f836-6461-4f7a-a75f-c5084a292897@github.com>

On Wed, 4 Oct 2023 19:15:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing returns when statx is available

The additions to UnixNativeDispatcher looks okay, I'd just prefer for statx_wrapper to have the same sig as statx if possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1751709969

From sgehwolf at openjdk.org  Mon Oct  9 10:08:17 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Oct 2023 10:08:17 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <UK67ODZ6NVLWfT_sVCP33BRmfw5iZ9NNOpSK7EZWOMg=.e3aeb90a-672e-46c1-843f-c18b766f77f2@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
 <UK67ODZ6NVLWfT_sVCP33BRmfw5iZ9NNOpSK7EZWOMg=.e3aeb90a-672e-46c1-843f-c18b766f77f2@github.com>
Message-ID: <ng2PCQVmeoHmFYPjzjVw3IOTBrAVmQ2KfFBmWj19V0g=.158a7725-f819-41ab-8f9d-5baf415fa896@github.com>

On Sat, 7 Oct 2023 12:58:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing returns when statx is available
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96:
> 
>> 94:             System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead);
>> 95:             // Creation time updates are not supported on Linux
>> 96:             supportsCreationTimeWrite = false;
> 
> It might be simpler to use `Linker.nativeLinker().defaultLookup().find("statx").isPresent()` as that would avoid adding CreationTimeHelper. JEP 454 is proposed to target 22 so the test won't need @enablePreview.

OK. If I use that this patch will have to wait for https://github.com/openjdk/jdk/pull/15103 to get integrated before this can be merged (avoiding the need to add `@enablePreview`). But that should happen fairly soon so it should be fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350058442

From sgehwolf at openjdk.org  Mon Oct  9 10:27:09 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Oct 2023 10:27:09 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <3yg6BZX9C1esvVPAFmGt60AykzyDj7PQeZ27weyyOTE=.bd37a111-0a6c-462a-b92c-4aa40363d02f@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
 <3yg6BZX9C1esvVPAFmGt60AykzyDj7PQeZ27weyyOTE=.bd37a111-0a6c-462a-b92c-4aa40363d02f@github.com>
Message-ID: <JNiQZ2tDUNzpR8c9zeCeb_r3pH0ZZw9KOAKV7vOeZfk=.a73d9565-16c3-4862-85d5-ddf6413b18b7@github.com>

On Sat, 7 Oct 2023 13:09:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing returns when statx is available
>
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 281:
> 
>> 279:                          int follow_symlink) {
>> 280:     if (follow_symlink == NO_FOLLOW_SYMLINK) {
>> 281:       flags |= AT_SYMLINK_NOFOLLOW;
> 
> I think it would be better if statx_wrapper had the same signature as statx. Have you tried adding the AT_SYMLINK_NOFOLLOW flag at the use-site?

Sure, I can do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350115255

From sgehwolf at openjdk.org  Mon Oct  9 10:27:11 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Oct 2023 10:27:11 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <ng2PCQVmeoHmFYPjzjVw3IOTBrAVmQ2KfFBmWj19V0g=.158a7725-f819-41ab-8f9d-5baf415fa896@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
 <UK67ODZ6NVLWfT_sVCP33BRmfw5iZ9NNOpSK7EZWOMg=.e3aeb90a-672e-46c1-843f-c18b766f77f2@github.com>
 <ng2PCQVmeoHmFYPjzjVw3IOTBrAVmQ2KfFBmWj19V0g=.158a7725-f819-41ab-8f9d-5baf415fa896@github.com>
Message-ID: <zvzxgW2Zef3nT4H54lh1KvOoD4-5X3vjP1Ql5sePfKc=.4e067145-ff65-4ee5-a99d-598d5e458821@github.com>

On Mon, 9 Oct 2023 09:25:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96:
>> 
>>> 94:             System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead);
>>> 95:             // Creation time updates are not supported on Linux
>>> 96:             supportsCreationTimeWrite = false;
>> 
>> It might be simpler to use `Linker.nativeLinker().defaultLookup().find("statx").isPresent()` as that would avoid adding CreationTimeHelper. JEP 454 is proposed to target 22 so the test won't need @enablePreview.
>
> OK. If I use that this patch will have to wait for https://github.com/openjdk/jdk/pull/15103 to get integrated before this can be merged (avoiding the need to add `@enablePreview`). But that should happen fairly soon so it should be fine.

For now I'm still using `@enablePreview` and will drop before integration once it's ready.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350119526

From mbaesken at openjdk.org  Mon Oct  9 10:31:01 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Oct 2023 10:31:01 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v4]
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <3CERRSFZlqfnqs98NVNF23znQliGdMtBPqff3GhnHsI=.87b05e01-3711-4121-acc1-e6e4ea536acf@github.com>

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

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

  replace windows handleSocketError

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16057/files
  - new: https://git.openjdk.org/jdk/pull/16057/files/c3b7e85d..d5137560

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

  Stats: 27 lines in 5 files changed: 9 ins; 8 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/16057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057

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

From mbaesken at openjdk.org  Mon Oct  9 10:31:02 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Oct 2023 10:31:02 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v3]
In-Reply-To: <ExV4fJML9zE_Bwi64PL4zUMi0xJ8H7riJzCjiVJpfCs=.a56f5840-5b43-49cd-b1ec-ab65a5ee1279@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com>
 <ExV4fJML9zE_Bwi64PL4zUMi0xJ8H7riJzCjiVJpfCs=.a56f5840-5b43-49cd-b1ec-ab65a5ee1279@github.com>
Message-ID: <BUIE2EDyjR4eU3MOWhqxvwtwtAsuUlFg6o2m0UmeirA=.4be8ddbc-a6fe-4c9e-bec6-074e31f5517b@github.com>

On Sat, 7 Oct 2023 12:41:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Moving to using NET_ThrowNew is okay but it creates inconsistencies that have to be fixed. I think this PR will go through a few iterations.
> 
> Some background here is that the socket code no longer exists in libnet/net.dll and at some point we need to do some cleanup and refactoring so that libnio does not have libnet as a dependency (if you go through the JBS issue you'll see a number of startup/first-use issues caused by this dependency). We don't have to do this as part of this PR of course but it provides some context.
> 
> For this PR, the issue with changing the specific functions to use NET_ThrowNet is that handleSocketError is left in place for DatagramChannelImpl.c, IOUtil.c and UnixDomainSocket.c. We shouldn't do that. We either replace usages (and remove handleSocketError) or change the existing function to take an additional message.

Okay, let's remove then the usages in the files you mentioned.

> src/java.base/windows/native/libnio/ch/Net.c line 559:
> 
>> 557:     int n = setGroupSourceReqOption(env, fdo, opt, group, index, source);
>> 558:     if (n == SOCKET_ERROR) {
>> 559:         NET_ThrowNew(env, WSAGetLastError(), "setsockopt with group source request");
> 
> That message looks odd, I think you want "setsocketopt to block or unblock source".

Thanks, I adjusted the message.

> src/java.base/windows/native/libnio/ch/Net.c line 638:
> 
>> 636:     int count = 0;
>> 637:     if (NET_SocketAvailable(fdval(env, fdo), &count) != 0) {
>> 638:         NET_ThrowNew(env, WSAGetLastError(), "socket availability check");
> 
> This should be "ioctlsocket", not ""socket availability check". Better still would be to just replace the usage of NET_SocketAvailable to use ioctlsocket directly as we will eventually remove NET_SocketAvailable.

okay then let's use  ioctlsocket . We could  completely remove  NET_SocketAvailable.  but in a follow up.

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1752712706
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350097325
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350098133

From mbaesken at openjdk.org  Mon Oct  9 11:54:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Oct 2023 11:54:55 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v5]
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <yLX1iiwOcESfQHQESG2jZZe7NgIGyswTANS4bTP1bnA=.a3c29a0a-0ff6-400b-ac35-10dee61eebd0@github.com>

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

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

  add missing quotation mark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16057/files
  - new: https://git.openjdk.org/jdk/pull/16057/files/d5137560..073a555c

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

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

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

From sgehwolf at openjdk.org  Mon Oct  9 13:12:58 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Oct 2023 13:12:58 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v11]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:

 - Keep wrapper function signature compatible to statx
 - Refactor test so as to use Linker from JEP 454.
   
   @enablePreview still needed as of yet. This can go once
   JDK-8312522 integrates.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/ad428030..1c4cac36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=09-10

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

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

From sgehwolf at openjdk.org  Mon Oct  9 13:13:00 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Oct 2023 13:13:00 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v10]
In-Reply-To: <G59ZVZaz-wsjonzubBSAk-CafiPAzkYIxbuhDfbCi3U=.b2c1f836-6461-4f7a-a75f-c5084a292897@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <Ynyi2RlemsHiIujvcOWbjoSPAgkeG4qAdR9SK4DGqPw=.480b07c6-48d6-43d4-997c-70439021730d@github.com>
 <G59ZVZaz-wsjonzubBSAk-CafiPAzkYIxbuhDfbCi3U=.b2c1f836-6461-4f7a-a75f-c5084a292897@github.com>
Message-ID: <5q7w0cmemjP6uyVSBSwKUxFFW7i7ucquIFq6GByRkcE=.5245ec21-cb80-4d15-b735-f4b8db4df436@github.com>

On Sat, 7 Oct 2023 13:13:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The additions to UnixNativeDispatcher looks okay, I'd just prefer for statx_wrapper to have the same sig as statx if possible.

All remaining issues should have been addressed in the latest version (modulo `@enablePreview`).

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1752979449

From sgehwolf at openjdk.org  Mon Oct  9 13:13:01 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Oct 2023 13:13:01 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v11]
In-Reply-To: <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
Message-ID: <gi4JtANnxfjSNFEDXetn7ET4GDeDfQSiyyWFyVwxJ2I=.758c6d71-bb43-4f5d-ad3e-2d04dbf06531@github.com>

On Mon, 9 Oct 2023 13:07:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Keep wrapper function signature compatible to statx
>  - Refactor test so as to use Linker from JEP 454.
>    
>    @enablePreview still needed as of yet. This can go once
>    JDK-8312522 integrates.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 30:

> 28:  * @library  ../.. /test/lib
> 29:  * @build jdk.test.lib.Platform
> 30:  * @enablePreview

FYI: This line won't be pushed as without it the test fails (currently).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350284105

From bpb at openjdk.org  Mon Oct  9 17:08:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 17:08:53 GMT
Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for
 CharSequence [v5]
In-Reply-To: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <WqwOcljK2qYInwq315NFXutSABIaShDb286qnX0xjrk=.bace5ca7-de33-48cf-9201-81af3f3aa7e8@github.com>

> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge
 - 4860681: Heap and direct buffer specializations
 - 4860681: Change some {@code ...} to <code>...</code> to prevent line breaking
 - 4860681: Modify existing test
 - Merge
 - 4860681: Add spaces to parameter lists in @see tag
 - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13744/files
  - new: https://git.openjdk.org/jdk/pull/13744/files/9e1ce482..90eee4e9

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

  Stats: 276664 lines in 5667 files changed: 118687 ins; 101301 del; 56676 mod
  Patch: https://git.openjdk.org/jdk/pull/13744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13744/head:pull/13744

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

From bpb at openjdk.org  Mon Oct  9 17:55:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 17:55:57 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS
In-Reply-To: <FebecvVbTrLqiOg81I0foEh1MKPkgMSu3iLKmktZaFE=.cdf3f255-5b50-4ddf-9c08-df3c440a5702@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
 <FebecvVbTrLqiOg81I0foEh1MKPkgMSu3iLKmktZaFE=.cdf3f255-5b50-4ddf-9c08-df3c440a5702@github.com>
Message-ID: <aoXYs6tfTUbalMk94KON0NKrgAJ3HFpc_VLpu9gYT9Q=.ada15295-0117-44e1-9eb7-f3f94a5a4589@github.com>

On Sat, 7 Oct 2023 06:22:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32.
>
> test/jdk/java/nio/file/Files/CopyAndMove.java line 158:
> 
>> 156:                                   attrs1.fileKey(), attrs1.lastModifiedTime());
>> 157:                 System.err.format("File time for %s is %s\n",
>> 158:                                   attrs2.fileKey(), attrs2.lastModifiedTime());
> 
> Are you 150% sure this is reliable?

According to [1],

"[...] the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds and access time has a resolution of 1 day [...]"

where "write time" is "last modified time." The testing I have done has thus far borne this out.

[1] [File Times](https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1350621134

From bpb at openjdk.org  Mon Oct  9 18:04:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 18:04:05 GMT
Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for
 CharSequence [v5]
In-Reply-To: <WqwOcljK2qYInwq315NFXutSABIaShDb286qnX0xjrk=.bace5ca7-de33-48cf-9201-81af3f3aa7e8@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <WqwOcljK2qYInwq315NFXutSABIaShDb286qnX0xjrk=.bace5ca7-de33-48cf-9201-81af3f3aa7e8@github.com>
Message-ID: <tTa4jO7u0PS9c1vr7Okt8lpsKljRDG53-wIwjDAHcmM=.a4af4ab8-7336-466d-bebe-f94c73504dd9@github.com>

On Mon, 9 Oct 2023 17:08:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge
>  - 4860681: Heap and direct buffer specializations
>  - 4860681: Change some {@code ...} to <code>...</code> to prevent line breaking
>  - 4860681: Modify existing test
>  - Merge
>  - 4860681: Add spaces to parameter lists in @see tag
>  - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence

Ping

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

PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1753432152

From alanb at openjdk.org  Mon Oct  9 18:38:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Oct 2023 18:38:06 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v11]
In-Reply-To: <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
Message-ID: <BdQSJvIvXQ2tv8-jtI6U-eXpVisp706TWYuG6IJxDGA=.f9466907-0ef9-4bb1-9f40-74f2dd1fce8d@github.com>

On Mon, 9 Oct 2023 13:12:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Keep wrapper function signature compatible to statx
>  - Refactor test so as to use Linker from JEP 454.
>    
>    @enablePreview still needed as of yet. This can go once
>    JDK-8312522 integrates.

The update to UnixNativeDispatcher.c looks okay now.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 30:

> 28:  * @library  ../.. /test/lib
> 29:  * @build jdk.test.lib.Platform
> 30:  * @enablePreview

It doesn't matter but I think the convention is to put `@enablePreview` before `@library` and `@build`.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96:

> 94:             // Creation time read depends on statx system call support
> 95:             supportsCreationTimeRead = Linker.nativeLinker().defaultLookup().find("statx").isPresent();
> 96:             System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead);

I think you left a debug statement here, or if you didn't then maybe drop the work "Debug" as it looks out of place here.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1665083160
PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350674479
PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350675005

From alanb at openjdk.org  Mon Oct  9 18:41:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Oct 2023 18:41:03 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v5]
In-Reply-To: <yLX1iiwOcESfQHQESG2jZZe7NgIGyswTANS4bTP1bnA=.a3c29a0a-0ff6-400b-ac35-10dee61eebd0@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <yLX1iiwOcESfQHQESG2jZZe7NgIGyswTANS4bTP1bnA=.a3c29a0a-0ff6-400b-ac35-10dee61eebd0@github.com>
Message-ID: <oJOIjzAL4TiUWiH8dGrfZeey1wfFtCYI68hUr9-UOAI=.b17f1795-40dc-4634-8941-79334b97d100@github.com>

On Mon, 9 Oct 2023 11:54:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing quotation mark

src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c line 92:

> 90:     rv = connect((SOCKET)fd, &sa.sa, sa_len);
> 91:     if (rv == SOCKET_ERROR) {
> 92:         NET_ThrowNew(env, WSAGetLastError(), "connect");

Can you check the copyright date on this and the other files as some of these haven't been updated in a while.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350680210

From alanb at openjdk.org  Mon Oct  9 18:46:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Oct 2023 18:46:02 GMT
Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows
 Net.c for extended exception messages [v5]
In-Reply-To: <yLX1iiwOcESfQHQESG2jZZe7NgIGyswTANS4bTP1bnA=.a3c29a0a-0ff6-400b-ac35-10dee61eebd0@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <yLX1iiwOcESfQHQESG2jZZe7NgIGyswTANS4bTP1bnA=.a3c29a0a-0ff6-400b-ac35-10dee61eebd0@github.com>
Message-ID: <hgTjMUiTZuCDO9sW8noDSfLh3vlU_y8lAXdgBOQUtwc=.0874e1ff-d5dd-45ae-8127-aec056ade2c4@github.com>

On Mon, 9 Oct 2023 11:54:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing quotation mark

So I think this version looks okay. We should probably rename the JBS issue and the PR as the change is no longer a handleSocketWithMessage function.

src/java.base/windows/native/libnio/ch/Net.c line 556:

> 554:             NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to block source");
> 555:         } else {
> 556:             NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to unblock source");

I think this can be reduced to one message (block or unblock) source as it doesn't add value as the stack trace will make it very clear if a source-specific block or unblock op.

src/java.base/windows/native/libnio/ch/Net.c line 636:

> 634:     u_long arg;
> 635:     if (ioctlsocket((SOCKET) fdval(env, fdo), FIONREAD, &arg) == SOCKET_ERROR) {
> 636:         NET_ThrowNew(env, WSAGetLastError(), "ioctlsocket");

Thanks for doing this, we should have removed the use of NET_SocketAvailable here a long time ago (same thing in the Unix code).

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

PR Review: https://git.openjdk.org/jdk/pull/16057#pullrequestreview-1665094335
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350683877
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350684981

From bpb at openjdk.org  Mon Oct  9 19:00:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 19:00:02 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS [v2]
In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
Message-ID: <ZtFZM_QcMAREdC0NBSScQSddt9UV9CgDYv72AqTf10s=.48408e3e-4a83-4106-8339-3d41520266ad@github.com>

> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32.

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

  8317687: Return false for "unix" view of FAT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16084/files
  - new: https://git.openjdk.org/jdk/pull/16084/files/ff938a04..0cc942c2

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

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

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

From bpb at openjdk.org  Mon Oct  9 19:00:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 19:00:05 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS [v2]
In-Reply-To: <FebecvVbTrLqiOg81I0foEh1MKPkgMSu3iLKmktZaFE=.cdf3f255-5b50-4ddf-9c08-df3c440a5702@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
 <FebecvVbTrLqiOg81I0foEh1MKPkgMSu3iLKmktZaFE=.cdf3f255-5b50-4ddf-9c08-df3c440a5702@github.com>
Message-ID: <I7GAt6AxOcH19GbR4dG2dOLjKyQC-i0r2U6VFzeWcE0=.6b694f4c-1585-4101-a313-c7f214042e25@github.com>

On Sat, 7 Oct 2023 06:22:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8317687: Return false for "unix" view of FAT
>
> src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 107:
> 
>> 105:         if (type == PosixFileAttributeView.class &&
>> 106:             entry().fstype().equals("msdos"))
>> 107:             return false;
> 
> I suspect supportsFileAttributeView(String) will need to be changed to return false if the view name is "unix".

Yes. Changed in 0cc942c2c3d888cf90f7fcc0dd8fb6c50de616cf.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1350697416

From bpb at openjdk.org  Mon Oct  9 19:38:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 19:38:02 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v11]
In-Reply-To: <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
Message-ID: <GEeHMYne_FXeiTPur2wrDqYE8xTMfWnnvCHTYWLySs8=.8133b167-ad95-4f1b-b867-a0390b37bb16@github.com>

On Mon, 9 Oct 2023 13:12:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Keep wrapper function signature compatible to statx
>  - Refactor test so as to use Linker from JEP 454.
>    
>    @enablePreview still needed as of yet. This can go once
>    JDK-8312522 integrates.

Nice to see the test C code gone.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1665154207

From rriggs at openjdk.org  Mon Oct  9 20:47:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Oct 2023 20:47:06 GMT
Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for
 CharSequence [v5]
In-Reply-To: <WqwOcljK2qYInwq315NFXutSABIaShDb286qnX0xjrk=.bace5ca7-de33-48cf-9201-81af3f3aa7e8@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <WqwOcljK2qYInwq315NFXutSABIaShDb286qnX0xjrk=.bace5ca7-de33-48cf-9201-81af3f3aa7e8@github.com>
Message-ID: <yZ8iRYiMxim2d-EzYkPqSPdO_y2HisaEUGNebn8JhIA=.4f56e16c-5bbb-4003-90b7-307b8a02d417@github.com>

On Mon, 9 Oct 2023 17:08:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge
>  - 4860681: Heap and direct buffer specializations
>  - 4860681: Change some {@code ...} to <code>...</code> to prevent line breaking
>  - 4860681: Modify existing test
>  - Merge
>  - 4860681: Add spaces to parameter lists in @see tag
>  - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence

The API spec for put looks fine.

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 542:

> 540:                     sb.getChars(start, start + count, buf, 0);
> 541:                 } else if (csq instanceof StringBuffer sb) {
> 542:                     sb.getChars(start, start + count, buf, 0);

Can the allocation and double copy be avoided?
But I guess the combinatorics of latin1/utf16 string encoding and the memory and byte order make it difficult.

test/jdk/java/nio/Buffer/Basic-X.java.template line 636:

> 634:         long seed = System.nanoTime();
> 635:         Random rnd = new Random(seed);
> 636: 

Printing the seed would make it possible to repeat the same test.

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

PR Review: https://git.openjdk.org/jdk/pull/13744#pullrequestreview-1665197849
PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1350764882
PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1350754116

From bpb at openjdk.org  Mon Oct  9 21:19:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 21:19:37 GMT
Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for
 CharSequence [v6]
In-Reply-To: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <XA2IKkx3056HBqJYnnTV-YeP0xa2MLC2z62QkG9pAAY=.7f93eeaf-579b-45d5-adf5-37122ef094e7@github.com>

> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s.

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

  4860681: Make test use RandomFactory

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13744/files
  - new: https://git.openjdk.org/jdk/pull/13744/files/90eee4e9..2ea96eed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=04-05

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

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

From bpb at openjdk.org  Mon Oct  9 21:19:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 21:19:44 GMT
Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for
 CharSequence [v5]
In-Reply-To: <yZ8iRYiMxim2d-EzYkPqSPdO_y2HisaEUGNebn8JhIA=.4f56e16c-5bbb-4003-90b7-307b8a02d417@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <WqwOcljK2qYInwq315NFXutSABIaShDb286qnX0xjrk=.bace5ca7-de33-48cf-9201-81af3f3aa7e8@github.com>
 <yZ8iRYiMxim2d-EzYkPqSPdO_y2HisaEUGNebn8JhIA=.4f56e16c-5bbb-4003-90b7-307b8a02d417@github.com>
Message-ID: <UUDa6_eL9FqaL0rAYxqv55re97_qlSKvYWXWjQEThxQ=.c1d8a56b-51a7-471c-afe9-f582e6b174f5@github.com>

On Mon, 9 Oct 2023 20:31:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge
>>  - 4860681: Heap and direct buffer specializations
>>  - 4860681: Change some {@code ...} to <code>...</code> to prevent line breaking
>>  - 4860681: Modify existing test
>>  - Merge
>>  - 4860681: Add spaces to parameter lists in @see tag
>>  - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 542:
> 
>> 540:                     sb.getChars(start, start + count, buf, 0);
>> 541:                 } else if (csq instanceof StringBuffer sb) {
>> 542:                     sb.getChars(start, start + count, buf, 0);
> 
> Can the allocation and double copy be avoided?
> But I guess the combinatorics of latin1/utf16 string encoding and the memory and byte order make it difficult.

Back when I was originally developing this change I could not see any better way to do this part.

> test/jdk/java/nio/Buffer/Basic-X.java.template line 636:
> 
>> 634:         long seed = System.nanoTime();
>> 635:         Random rnd = new Random(seed);
>> 636: 
> 
> Printing the seed would make it possible to repeat the same test.

So modified in 2ea96eed0bba75e1126ede5de31ebbb05950d663.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1350793218
PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1350792811

From mbaesken at openjdk.org  Tue Oct 10 07:57:46 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Oct 2023 07:57:46 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v6]
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <s9ymQT3_XSfElkBAAyyGGKpwCrMR2Xj4AaU2iBs8lWo=.a6799ee7-0eff-4c6d-a8db-0f842687085d@github.com>

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

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

  COPYRIGHT headers and minor adjustments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16057/files
  - new: https://git.openjdk.org/jdk/pull/16057/files/073a555c..2fe42bd9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=04-05

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

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

From mbaesken at openjdk.org  Tue Oct 10 07:57:49 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Oct 2023 07:57:49 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v5]
In-Reply-To: <yLX1iiwOcESfQHQESG2jZZe7NgIGyswTANS4bTP1bnA=.a3c29a0a-0ff6-400b-ac35-10dee61eebd0@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <yLX1iiwOcESfQHQESG2jZZe7NgIGyswTANS4bTP1bnA=.a3c29a0a-0ff6-400b-ac35-10dee61eebd0@github.com>
Message-ID: <gYfdENQogOYxF_Lz6iqMuVhu0rp6vxWhg5MgE08lui0=.90d78a46-8114-471d-a880-ac14f8f113b3@github.com>

On Mon, 9 Oct 2023 11:54:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing quotation mark

Hi reviewers , are you fine with the latest version ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1754612245

From mbaesken at openjdk.org  Tue Oct 10 07:57:53 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Oct 2023 07:57:53 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v5]
In-Reply-To: <oJOIjzAL4TiUWiH8dGrfZeey1wfFtCYI68hUr9-UOAI=.b17f1795-40dc-4634-8941-79334b97d100@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <yLX1iiwOcESfQHQESG2jZZe7NgIGyswTANS4bTP1bnA=.a3c29a0a-0ff6-400b-ac35-10dee61eebd0@github.com>
 <oJOIjzAL4TiUWiH8dGrfZeey1wfFtCYI68hUr9-UOAI=.b17f1795-40dc-4634-8941-79334b97d100@github.com>
Message-ID: <lnQmzI-LkMQ1i8V4BbK77Q6JPdHebXAMszYQGJBfV3Q=.ae24f7fa-51ec-4d94-9f00-b393e5d671cd@github.com>

On Mon, 9 Oct 2023 18:38:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add missing quotation mark
>
> src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c line 92:
> 
>> 90:     rv = connect((SOCKET)fd, &sa.sa, sa_len);
>> 91:     if (rv == SOCKET_ERROR) {
>> 92:         NET_ThrowNew(env, WSAGetLastError(), "connect");
> 
> Can you check the copyright date on this and the other files as some of these haven't been updated in a while.

Hi Alan, I adjusted the copyright dates.

> src/java.base/windows/native/libnio/ch/Net.c line 556:
> 
>> 554:             NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to block source");
>> 555:         } else {
>> 556:             NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to unblock source");
> 
> I think this can be reduced to one message (block or unblock) source as it doesn't add value as the stack trace will make it very clear if a source-specific block or unblock op.

Okay, I reduced it to one message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1351755006
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1351756715

From alanb at openjdk.org  Tue Oct 10 08:23:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Oct 2023 08:23:00 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v6]
In-Reply-To: <s9ymQT3_XSfElkBAAyyGGKpwCrMR2Xj4AaU2iBs8lWo=.a6799ee7-0eff-4c6d-a8db-0f842687085d@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <s9ymQT3_XSfElkBAAyyGGKpwCrMR2Xj4AaU2iBs8lWo=.a6799ee7-0eff-4c6d-a8db-0f842687085d@github.com>
Message-ID: <nJU-ALNzvGytGJocIZ6Fh4mBwa3pWot17fmxrYXr9j4=.7862e712-7bda-49fc-9b76-63ed76935114@github.com>

On Tue, 10 Oct 2023 07:57:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   COPYRIGHT headers and minor adjustments

src/java.base/windows/native/libnio/ch/Net.c line 726:

> 724:             }
> 725:         } else if (optError != NO_ERROR) {
> 726:             NET_ThrowNew(env, optError, "getsockopt issue with option value");

I assume "getsockopt issue with option value" should be "getsockopt" here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1351844096

From sgehwolf at openjdk.org  Tue Oct 10 08:26:04 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Oct 2023 08:26:04 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v11]
In-Reply-To: <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
Message-ID: <G1VQ2_enJ2wva1LhcbrJZCzisJOHdQiNJmECTjR5Bw0=.e1bd9159-b001-443d-96a1-637346ba714b@github.com>

On Mon, 9 Oct 2023 13:12:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Keep wrapper function signature compatible to statx
>  - Refactor test so as to use Linker from JEP 454.
>    
>    @enablePreview still needed as of yet. This can go once
>    JDK-8312522 integrates.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1754677186

From sgehwolf at openjdk.org  Tue Oct 10 08:26:09 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Oct 2023 08:26:09 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v11]
In-Reply-To: <BdQSJvIvXQ2tv8-jtI6U-eXpVisp706TWYuG6IJxDGA=.f9466907-0ef9-4bb1-9f40-74f2dd1fce8d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
 <BdQSJvIvXQ2tv8-jtI6U-eXpVisp706TWYuG6IJxDGA=.f9466907-0ef9-4bb1-9f40-74f2dd1fce8d@github.com>
Message-ID: <HS8_cRufLhrNam3vflpe3u-usb8ilwjNHbdl-z95mdU=.5c96cc26-cc34-4f16-a143-4bd356f11434@github.com>

On Mon, 9 Oct 2023 18:33:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Keep wrapper function signature compatible to statx
>>  - Refactor test so as to use Linker from JEP 454.
>>    
>>    @enablePreview still needed as of yet. This can go once
>>    JDK-8312522 integrates.
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 30:
> 
>> 28:  * @library  ../.. /test/lib
>> 29:  * @build jdk.test.lib.Platform
>> 30:  * @enablePreview
> 
> It doesn't matter but I think the convention is to put `@enablePreview` before `@library` and `@build`.

This shouldn't matter indeed as I intend to push only once #15103 is pushed not needing the `@enablePreview` annotation.

> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96:
> 
>> 94:             // Creation time read depends on statx system call support
>> 95:             supportsCreationTimeRead = Linker.nativeLinker().defaultLookup().find("statx").isPresent();
>> 96:             System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead);
> 
> I think you left a debug statement here, or if you didn't then maybe drop the work "Debug" as it looks out of place here.

I can drop the `Debug` word, but would like to keep the rest as the test behaves differently whether or not `supportsCreationTimeRead` is true or not. On a `statx`-supporting system it would check that the modified time is different from the creation time. Otherwise it wouldn't. So it's nice to know which mode the test ran in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1351848302
PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1351843932

From alanb at openjdk.org  Tue Oct 10 08:27:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Oct 2023 08:27:01 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v6]
In-Reply-To: <s9ymQT3_XSfElkBAAyyGGKpwCrMR2Xj4AaU2iBs8lWo=.a6799ee7-0eff-4c6d-a8db-0f842687085d@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <s9ymQT3_XSfElkBAAyyGGKpwCrMR2Xj4AaU2iBs8lWo=.a6799ee7-0eff-4c6d-a8db-0f842687085d@github.com>
Message-ID: <uLjTiCMutbvM8ruW5qWt0AFEKGMFpRXkaZ_3iDStQEk=.c3a90e82-8f11-49b3-b4be-364fb030bfe9@github.com>

On Tue, 10 Oct 2023 07:57:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   COPYRIGHT headers and minor adjustments

src/java.base/windows/native/libnio/ch/Net.c line 541:

> 539: 
> 540:     if (n == SOCKET_ERROR) {
> 541:         NET_ThrowNew(env, WSAGetLastError(), error_message);

I this this one can be simplified to "setsockopt".  Source-specific multicast isn't widely used but if you did happen to get a failure here then the stack trace should make it very clear as it's a different join method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1351849380

From sgehwolf at openjdk.org  Tue Oct 10 08:31:50 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Oct 2023 08:31:50 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v12]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <Emm_dRcOXbAUfZCUxEhxVUbJ37ee0qS-2hs-9_0OmNU=.9c61ab7b-b853-4f27-b668-8725289ba244@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

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

  Drop word 'Debug:' in CreationTime test code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/1c4cac36..cdd0fd54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=10-11

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

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

From alanb at openjdk.org  Tue Oct 10 08:33:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Oct 2023 08:33:11 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v11]
In-Reply-To: <HS8_cRufLhrNam3vflpe3u-usb8ilwjNHbdl-z95mdU=.5c96cc26-cc34-4f16-a143-4bd356f11434@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
 <BdQSJvIvXQ2tv8-jtI6U-eXpVisp706TWYuG6IJxDGA=.f9466907-0ef9-4bb1-9f40-74f2dd1fce8d@github.com>
 <HS8_cRufLhrNam3vflpe3u-usb8ilwjNHbdl-z95mdU=.5c96cc26-cc34-4f16-a143-4bd356f11434@github.com>
Message-ID: <NeSV67NAIeflMYQwu-3ITTdeCbOZ4Z9py8xHoZIIbOs=.cde3e9ce-ce34-4bc3-94e2-440f057ddec5@github.com>

On Tue, 10 Oct 2023 08:20:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96:
>> 
>>> 94:             // Creation time read depends on statx system call support
>>> 95:             supportsCreationTimeRead = Linker.nativeLinker().defaultLookup().find("statx").isPresent();
>>> 96:             System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead);
>> 
>> I think you left a debug statement here, or if you didn't then maybe drop the work "Debug" as it looks out of place here.
>
> I can drop the `Debug` word, but would like to keep the rest as the test behaves differently whether or not `supportsCreationTimeRead` is true or not. On a `statx`-supporting system it would check that the modified time is different from the creation time. Otherwise it wouldn't. So it's nice to know which mode the test ran in.

If you do leave a trace message here then better to put it after the if-then-else so that it's clear on all platforms whether file create time is tested or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1351858240

From sgehwolf at openjdk.org  Tue Oct 10 08:38:06 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Oct 2023 08:38:06 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v11]
In-Reply-To: <NeSV67NAIeflMYQwu-3ITTdeCbOZ4Z9py8xHoZIIbOs=.cde3e9ce-ce34-4bc3-94e2-440f057ddec5@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <adpUTGCQ1n7qkUxNdi2xVK4CyTO1OWEWxyFUC0GNngY=.1f0e1d0e-8ac3-4ddf-9ea4-c87ab6d4a233@github.com>
 <BdQSJvIvXQ2tv8-jtI6U-eXpVisp706TWYuG6IJxDGA=.f9466907-0ef9-4bb1-9f40-74f2dd1fce8d@github.com>
 <HS8_cRufLhrNam3vflpe3u-usb8ilwjNHbdl-z95mdU=.5c96cc26-cc34-4f16-a143-4bd356f11434@github.com>
 <NeSV67NAIeflMYQwu-3ITTdeCbOZ4Z9py8xHoZIIbOs=.cde3e9ce-ce34-4bc3-94e2-440f057ddec5@github.com>
Message-ID: <R0MQ5jNT6vrCJQzkjfJN-lFQz2MMFYKtgV1nljeq3iY=.e0567061-5b2a-4ef1-9787-bbbb5db5ad95@github.com>

On Tue, 10 Oct 2023 08:30:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I can drop the `Debug` word, but would like to keep the rest as the test behaves differently whether or not `supportsCreationTimeRead` is true or not. On a `statx`-supporting system it would check that the modified time is different from the creation time. Otherwise it wouldn't. So it's nice to know which mode the test ran in.
>
> If you do leave a trace message here then better to put it after the if-then-else so that it's clear on all platforms whether file create time is tested or not.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1351863494

From sgehwolf at openjdk.org  Tue Oct 10 08:44:49 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Oct 2023 08:44:49 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v13]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <exrhsvh9UZLVfLRmmTxONmTPXBRpEAqq126jZgzE8vA=.687b64b2-a602-41fe-a9db-8a557b5e6dd3@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

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

  Move trace message after platform specific blocks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/cdd0fd54..cbb24e38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=11-12

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

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

From alanb at openjdk.org  Tue Oct 10 09:03:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Oct 2023 09:03:06 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v13]
In-Reply-To: <exrhsvh9UZLVfLRmmTxONmTPXBRpEAqq126jZgzE8vA=.687b64b2-a602-41fe-a9db-8a557b5e6dd3@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <exrhsvh9UZLVfLRmmTxONmTPXBRpEAqq126jZgzE8vA=.687b64b2-a602-41fe-a9db-8a557b5e6dd3@github.com>
Message-ID: <66OrTFZaXxlst-TvipIRxzw1oEQU7n7qZvF8hvSQpOA=.c8a61f50-e05d-4069-91cf-21c454835f07@github.com>

On Tue, 10 Oct 2023 08:44:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move trace message after platform specific blocks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1666959450

From mbaesken at openjdk.org  Tue Oct 10 09:24:37 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Oct 2023 09:24:37 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v7]
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <Sb5QNR84JmXeIfwYidw3b-zdv_iczjh4Zo9CFA1I1fA=.88d1a27f-1ea1-4720-9653-8d01a05398ca@github.com>

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

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

  adjust some messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16057/files
  - new: https://git.openjdk.org/jdk/pull/16057/files/2fe42bd9..a4175aa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=05-06

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

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

From mbaesken at openjdk.org  Tue Oct 10 09:24:37 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Oct 2023 09:24:37 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v6]
In-Reply-To: <s9ymQT3_XSfElkBAAyyGGKpwCrMR2Xj4AaU2iBs8lWo=.a6799ee7-0eff-4c6d-a8db-0f842687085d@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <s9ymQT3_XSfElkBAAyyGGKpwCrMR2Xj4AaU2iBs8lWo=.a6799ee7-0eff-4c6d-a8db-0f842687085d@github.com>
Message-ID: <Hjhv28VrAwr6oTmyRLiqcVtr90myajJ1UUMVbXfDMNg=.7ed15920-c01c-41c1-8525-790592af738b@github.com>

On Tue, 10 Oct 2023 07:57:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   COPYRIGHT headers and minor adjustments

Hi Alan, I simplified the 2 messages.

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1754794433

From alanb at openjdk.org  Tue Oct 10 09:48:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Oct 2023 09:48:15 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v7]
In-Reply-To: <Sb5QNR84JmXeIfwYidw3b-zdv_iczjh4Zo9CFA1I1fA=.88d1a27f-1ea1-4720-9653-8d01a05398ca@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <Sb5QNR84JmXeIfwYidw3b-zdv_iczjh4Zo9CFA1I1fA=.88d1a27f-1ea1-4720-9653-8d01a05398ca@github.com>
Message-ID: <ZlIyYLeyA0qB_3AH_W7-WsouaGLq9Wcybj9VrMDFmuY=.dd568234-f601-42ae-ae5b-797dfd1b9f9c@github.com>

On Tue, 10 Oct 2023 09:24:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust some messages

Marked as reviewed by alanb (Reviewer).

src/java.base/windows/native/libnio/ch/Net.c line 536:

> 534:         int opt = (join) ? MCAST_JOIN_SOURCE_GROUP : MCAST_LEAVE_SOURCE_GROUP;
> 535:         n = setGroupSourceReqOption(env, fdo, opt, group, index, source);
> 536: 

I assume this blank line isn't needed now.

src/java.base/windows/native/libnio/ch/Net.c line 552:

> 550:     int n = setGroupSourceReqOption(env, fdo, opt, group, index, source);
> 551:     if (n == SOCKET_ERROR) {
> 552:         NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to block or unblock source");

This message is okay although it can be reduced to "setsockopt" to be consistent with the others. If source filtering is used then the stack trace will be very clear if a source address is being blocked or unblocked.

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

PR Review: https://git.openjdk.org/jdk/pull/16057#pullrequestreview-1667076159
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1352035707
PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1352039763

From mbaesken at openjdk.org  Tue Oct 10 11:32:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Oct 2023 11:32:16 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v8]
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <qq7Pqsivdprc7cEo9pp-SdOt0Si3dFuLQp2EnKCiOrI=.a72e0376-a376-47d2-a79d-4735a568d2e2@github.com>

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

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

  remove blank line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16057/files
  - new: https://git.openjdk.org/jdk/pull/16057/files/a4175aa1..524285d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=06-07

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

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

From bpb at openjdk.org  Tue Oct 10 14:52:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Oct 2023 14:52:54 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v13]
In-Reply-To: <exrhsvh9UZLVfLRmmTxONmTPXBRpEAqq126jZgzE8vA=.687b64b2-a602-41fe-a9db-8a557b5e6dd3@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <exrhsvh9UZLVfLRmmTxONmTPXBRpEAqq126jZgzE8vA=.687b64b2-a602-41fe-a9db-8a557b5e6dd3@github.com>
Message-ID: <GkGmos_jy8alLTXAkFfBECJTX9tx02w8JM2LTMkTV20=.ac57f4f2-6fb1-4882-be0f-4b52c383e827@github.com>

On Tue, 10 Oct 2023 08:44:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move trace message after platform specific blocks

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1667982626

From djelinski at openjdk.org  Tue Oct 10 18:18:15 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Oct 2023 18:18:15 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v8]
In-Reply-To: <qq7Pqsivdprc7cEo9pp-SdOt0Si3dFuLQp2EnKCiOrI=.a72e0376-a376-47d2-a79d-4735a568d2e2@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <qq7Pqsivdprc7cEo9pp-SdOt0Si3dFuLQp2EnKCiOrI=.a72e0376-a376-47d2-a79d-4735a568d2e2@github.com>
Message-ID: <65RyYOEpbHNKfQI3PB_hoquyN0YPKyUq2YDxka1Bonk=.746b3a0b-231f-4f49-963f-afe884f50fef@github.com>

On Tue, 10 Oct 2023 11:32:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove blank line

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16057#pullrequestreview-1668536894

From brian.burkhalter at oracle.com  Tue Oct 10 18:31:15 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 10 Oct 2023 18:31:15 +0000
Subject: [Request for Comments] File extension redux
Message-ID: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com>

I would like to resurrect this topic which has languished for quite a while now. It was discussed for probably decades before my involvement with it. A brief outline of its most recent history is included below. The essence is that it would be good to add a java.nio.file.Path.getExtension method, and possibly one or more companion methods. General comments on the topic are welcome regardless of whether the included chronology is reviewed. Things to consider include:

1) whether a getExtension method ever returns null;
2) whether a period character is included as the first character of the returned extension;
3) whether the extension of ?foo? (no dot) differs from that of ?foo.? (terminal dot).

Thanks,

Brian

--- snip --- TL;DR --- snip ---

[1] Feb. 2018
Path.hasExtension was initially proposed but dropped in favor of Path.getExtension. This method was for the most common cases equivalent to

Path path = ...;
String name = path.getFileName();
String extension = name.substring(name.lastIndexOf(?.?) + 1);

which is to say the extension is the portion of the file name string after but not including the last period character (dot). This effort faded out.

[2] Apr. 2021 - Mar. 2022
A pull request was proposed and culminated in the proposal of the Path method

String getExtension(String defaultExtension)

where in the common case the extension is once again the portion of the file name string after the last dot. For degenerate cases the ?defaultExtension? parameter would be returned.  This effort was superseded by [3].

[3] Mar. 2022 - Dec. 2022

This pull request specified the Path method

String getExtension()

which in the common case returned the portion of the file name string after the last dot, and in unusual cases either the empty string (terminal dot) or null (no dot). For a time this proposal used Optional but that was dropped as unwieldy. This PR was approved and integrated.

[4] Dec. 2022

Due primarily to the undesirability of the possibility of a null return value and the lateness of the integration in the development cycle, the API added in [3] was backed out.

[5] Dec. 22

A new issue was filed to track the resumption of eventual work on this topic. This issue suggested that the last dot be included in the extension, e.g., the extension of ?image.jpg? would be ?.jpg? rather than ?jpg? and that the value returned by getExtension would never be null. It also proposed a complementary method Path.removeExtension which, together with Path.getExtension, would form an invariant

Path path = ...;
assert path.equals(path.removeExtension() + path.getExtension());

which would obviate the need to handle a period character explicitly.

[1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html
[2] https://github.com/openjdk/jdk/pull/2319
[3] https://github.com/openjdk/jdk/pull/8066
[4] https://github.com/openjdk/jdk/pull/11566
[5] https://bugs.openjdk.org/browse/JDK-8298318
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20231010/9cdf7b22/attachment.htm>

From jvernee at openjdk.org  Tue Oct 10 21:04:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 10 Oct 2023 21:04:24 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v35]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <mASawIb7neN3aUOh0lF7-MD8_nd_pgTV-OrhPidQhQg=.bce693ed-7c33-41d2-ada0-f3ea977ca359@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

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

  update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/b4a7b7ab..35ca1921

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=33-34

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

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

From roger.riggs at oracle.com  Tue Oct 10 21:31:35 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 10 Oct 2023 17:31:35 -0400
Subject: [Request for Comments] File extension redux
In-Reply-To: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com>
References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com>
Message-ID: <f869318d-8ad2-e17e-84fc-54e9fb7ba1bf@oracle.com>

Hi Brian,

First the intuition and then the rationale.

Intuition: the extension does not include the period '.' learned from 
years of working with existing systems, both shell and programming 
languages with file apis.

Second: In trying to make Path.getExtension() handle all of the use 
cases possible, it makes some of them more difficult.? In particular, 
the cases for removing or replacing the extension are easier to do with 
a method for that purpose. It is easier to explain using a 
Path.removeExtension() method than to explain how to convert the path to 
a string and then remove some number of characters from the end and 
recreate the Path.

Rationale:

  * Other Java libraries that provide path name utilities do not include
    the dot as part of the extension; (Guava and Apache Commons). A
    mismatch with them (and other common Java libraries) creates
    friction and room to make mistakes in conversions between different
    representations.
  * The no-dot representation works just fine except in the case of
    trailing dot, which is quite uncommon in practice.
  * The APIs provided should do what the programmer needs to do, not be
    APIs from which the programmer can create the API they need and
    still avoid an explosion of APIs for narrow use cases.
  * Extensions are used in many ways, from switch statements to keys in
    maps to simple if/then/else; some are hard coded and others are
    configured or loaded as plugins. The semantics should be simple and
    direct.

For 1) and 3) I would say that both "foo" or "foo." have an empty ("") 
extension.
Providing a removeExtension() or replaceExtension(String) method can 
embed the edge case handling and make the API easy to use without having 
to burden the Path.getExtension() method with a model that includes that 
complexity.

Regards, Roger


On 10/10/23 2:31 PM, Brian Burkhalter wrote:
> I would like to resurrect this topic which has languished for quite a 
> while now. It was discussed for probably decades before my involvement 
> with it. A brief outline of its most recent history is included below. 
> The essence is that it would be good to add a 
> java.nio.file.Path.getExtension method, and possibly one or more 
> companion methods. General comments on the topic are welcome 
> regardless of whether the included chronology is reviewed. Things to 
> consider include:
>
> 1) whether a getExtension method ever returns null;
> 2) whether a period character is included as the first character of 
> the returned extension;
> 3) whether the extension of ?foo? (no dot) differs from that of ?foo.? 
> (terminal dot).
>
> Thanks,
>
> Brian
>
> --- snip --- TL;DR --- snip ---
>
> [1] Feb. 2018
> Path.hasExtension was initially proposed but dropped in favor of 
> Path.getExtension. This method was for the most common cases equivalent to
>
> Path path = ...;
> String name = path.getFileName();
> String extension = name.substring(name.lastIndexOf(?.?) + 1);
>
> which is to say the extension is the portion of the file name string 
> after but not including the last period character (dot). This effort 
> faded out.
>
> [2] Apr. 2021 - Mar. 2022
> A pull request was proposed and culminated in the proposal of the Path 
> method
>
> String getExtension(String defaultExtension)
>
> where in the common case the extension is once again the portion of 
> the file name string after the last dot. For degenerate cases the 
> ?defaultExtension? parameter would be returned.? This effort was 
> superseded by [3].
>
> [3] Mar. 2022 - Dec. 2022
>
> This pull request specified the Path method
>
> String getExtension()
>
> which in the common case returned the portion of the file name string 
> after the last dot, and in unusual cases either the empty string 
> (terminal dot) or null (no dot). For a time this proposal used 
> Optional but that was dropped as unwieldy. This PR was approved and 
> integrated.
>
> [4] Dec. 2022
>
> Due primarily to the undesirability of the possibility of a null 
> return value and the lateness of the integration in the development 
> cycle, the API added in [3] was backed out.
>
> [5] Dec. 22
>
> A new issue was filed to track the resumption of eventual work on this 
> topic. This issue suggested that the last dot be included in the 
> extension, e.g., the extension of ?image.jpg? would be ?.jpg? rather 
> than ?jpg? and that the value returned by getExtension would never be 
> null. It also proposed a complementary method Path.removeExtension 
> which, together with Path.getExtension, would form an invariant
>
> Path path = ...;
> assert path.equals(path.removeExtension() + path.getExtension());
>
> which would obviate the need to handle a period character explicitly.
>
> [1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html
> [2] https://github.com/openjdk/jdk/pull/2319
> [3] https://github.com/openjdk/jdk/pull/8066
> [4] https://github.com/openjdk/jdk/pull/11566
> [5] https://bugs.openjdk.org/browse/JDK-8298318
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20231010/9b47365c/attachment.htm>

From jvernee at openjdk.org  Tue Oct 10 23:17:17 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 10 Oct 2023 23:17:17 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v36]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <OWlbP1TJwCKwgmbjInkSyOCU8w7zbIdCBHVZacS4ON8=.162138b7-44f0-46b7-b16b-3d8cb8891500@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

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

  adjust misformatted copyright headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/35ca1921..5cf9e753

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=34-35

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

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

From clanger at openjdk.org  Wed Oct 11 05:48:39 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 11 Oct 2023 05:48:39 GMT
Subject: RFR: 8317839: Exclude
 java/nio/channels/Channels/SocketChannelStreams.java on AIX
Message-ID: <pP8lzkDvUqF9xlIwOUWFXCqmvQSmbX6VkC5f23j5Uhk=.98dbf685-8a89-4980-8e2f-0f426bc3b598@github.com>

The test java/nio/channels/Channels/SocketChannelStreams.java often times out on AIX and should be excluded.

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

Commit messages:
 - JDK-8317839

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

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

From alanb at openjdk.org  Wed Oct 11 05:53:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Oct 2023 05:53:08 GMT
Subject: RFR: 8317839: Exclude
 java/nio/channels/Channels/SocketChannelStreams.java on AIX
In-Reply-To: <pP8lzkDvUqF9xlIwOUWFXCqmvQSmbX6VkC5f23j5Uhk=.98dbf685-8a89-4980-8e2f-0f426bc3b598@github.com>
References: <pP8lzkDvUqF9xlIwOUWFXCqmvQSmbX6VkC5f23j5Uhk=.98dbf685-8a89-4980-8e2f-0f426bc3b598@github.com>
Message-ID: <2oZNEGggEa9MUCGK1zAye203ihTCLfQQUes-1-OaWzo=.82f52f09-9c00-4807-b6a9-24c7bc5d07b9@github.com>

On Tue, 10 Oct 2023 21:45:46 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test java/nio/channels/Channels/SocketChannelStreams.java often times out on AIX and should be excluded.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16129#pullrequestreview-1669989720

From mbaesken at openjdk.org  Wed Oct 11 06:44:11 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 06:44:11 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v8]
In-Reply-To: <qq7Pqsivdprc7cEo9pp-SdOt0Si3dFuLQp2EnKCiOrI=.a72e0376-a376-47d2-a79d-4735a568d2e2@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <qq7Pqsivdprc7cEo9pp-SdOt0Si3dFuLQp2EnKCiOrI=.a72e0376-a376-47d2-a79d-4735a568d2e2@github.com>
Message-ID: <qSSQRtp7QIkjXL7cdw-Tl7APyp2ghg0IsPTxH6wHYWo=.b2ba72b6-9c67-4821-9eb8-732be6f0b0de@github.com>

On Tue, 10 Oct 2023 11:32:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove blank line

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1756936040

From mbaesken at openjdk.org  Wed Oct 11 06:47:26 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 06:47:26 GMT
Subject: Integrated: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win)
In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
Message-ID: <GTYD4x7m1a161MIbJxkFxjuL_6Mijm_5YqVFy3jNvhU=.bfb16f57-d8b0-4bf5-ac45-cd5bd294c088@github.com>

On Thu, 5 Oct 2023 14:33:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
> This leads sometimes to exceptions like
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> 
> see https://bugs.openjdk.org/browse/JDK-8317307
> 
> It would be better to have a message explaining the reason instead of "no further information" .

This pull request has now been integrated.

Changeset: a9b41da9
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9b41da9df398ae7e2cf598b2779808d16504e14
Stats:     39 lines in 5 files changed: 5 ins; 8 del; 26 mod

8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win)

Reviewed-by: vtewari, alanb, djelinski

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

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

From clanger at openjdk.org  Wed Oct 11 06:57:18 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 11 Oct 2023 06:57:18 GMT
Subject: Integrated: 8317839: Exclude
 java/nio/channels/Channels/SocketChannelStreams.java on AIX
In-Reply-To: <pP8lzkDvUqF9xlIwOUWFXCqmvQSmbX6VkC5f23j5Uhk=.98dbf685-8a89-4980-8e2f-0f426bc3b598@github.com>
References: <pP8lzkDvUqF9xlIwOUWFXCqmvQSmbX6VkC5f23j5Uhk=.98dbf685-8a89-4980-8e2f-0f426bc3b598@github.com>
Message-ID: <xjmg3E-d0JY3TosMqGXD68scFGltHbVx4gMQR0DzY28=.75810ffa-969f-4bac-8c57-b681399b5415@github.com>

On Tue, 10 Oct 2023 21:45:46 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test java/nio/channels/Channels/SocketChannelStreams.java often times out on AIX and should be excluded.

This pull request has now been integrated.

Changeset: ca96fd3b
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca96fd3b07958a7de6274bd945490bb9e79c2170
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8317839: Exclude java/nio/channels/Channels/SocketChannelStreams.java on AIX

Reviewed-by: alanb

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

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

From mbaesken at openjdk.org  Wed Oct 11 08:06:21 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 08:06:21 GMT
Subject: RFR: JDK-8317603: Improve exception messages thrown by
 sun.nio.ch.Net native methods (win) [v8]
In-Reply-To: <qq7Pqsivdprc7cEo9pp-SdOt0Si3dFuLQp2EnKCiOrI=.a72e0376-a376-47d2-a79d-4735a568d2e2@github.com>
References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com>
 <qq7Pqsivdprc7cEo9pp-SdOt0Si3dFuLQp2EnKCiOrI=.a72e0376-a376-47d2-a79d-4735a568d2e2@github.com>
Message-ID: <LAasELL9liE1zoHejuJd9wcTKs2G1uRjJCZ5G95Varc=.8f5f8258-6320-4672-a540-5a239b44d352@github.com>

On Tue, 10 Oct 2023 11:32:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding.  On Unix we have this function. 
>> This leads sometimes to exceptions like
>> 
>> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
>> 
>> see https://bugs.openjdk.org/browse/JDK-8317307
>> 
>> It would be better to have a message explaining the reason instead of "no further information" .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove blank line

created https://github.com/openjdk/jdk/pull/16057#pullrequestreview-1668536894   for the suggested NET_SocketAvailable removal/replacement .

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

PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1757072147

From mbaesken at openjdk.org  Wed Oct 11 08:08:05 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 08:08:05 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
Message-ID: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>

When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

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

Commit messages:
 - JDK-8317866

Changes: https://git.openjdk.org/jdk/pull/16139/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16139&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317866
  Stats: 34 lines in 4 files changed: 4 ins; 27 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16139/head:pull/16139

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

From pminborg at openjdk.org  Wed Oct 11 09:08:40 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 09:08:40 GMT
Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer
Message-ID: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>

This PR proposed to Add @sealedGraph to `ByteBuffer`.

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

Commit messages:
 - Add @sealedGraph to ByteBuffer

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

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

From dfuchs at openjdk.org  Wed Oct 11 10:45:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Oct 2023 10:45:10 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <lFGgC6Mt7IyABYSGSn1u2C3QJRVqCgXb-gs5pW6Wo8Y=.e274ae84-7a14-46d2-a5d8-e888d0eab894@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

This looks reasonable. Thanks for the cleanup! 
Let me run some test before approving.

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

PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1670752677

From alanb at openjdk.org  Wed Oct 11 11:11:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Oct 2023 11:11:15 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <GFNSW49zXHZWQrB7g56yH5ug0JftvKALSRSi_mdLuZQ=.d7cf22b6-c39b-4a4b-b287-ef77d6f424f9@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1670860910

From mbaesken at openjdk.org  Wed Oct 11 13:42:28 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 13:42:28 GMT
Subject: RFR: JDK-8038244: (fs) Check return value of malloc in
 Java_sun_nio_fs_AixNativeDispatcher_getmntctl()
Message-ID: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>

There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory).

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

Commit messages:
 - JDK-8038244

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

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

From rriggs at openjdk.org  Wed Oct 11 14:02:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Oct 2023 14:02:19 GMT
Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer
In-Reply-To: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
References: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
Message-ID: <qNZ529BQmXjBHP-aivRhiOYoaHTCzda7A3nu8ovt2uc=.3a87fcad-9046-4a4c-9ad4-a4435bb0f984@github.com>

On Wed, 11 Oct 2023 08:59:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to Add @sealedGraph to `ByteBuffer`.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16142#pullrequestreview-1671319653

From bpb at openjdk.org  Wed Oct 11 15:21:11 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Oct 2023 15:21:11 GMT
Subject: RFR: JDK-8038244: (fs) Check return value of malloc in
 Java_sun_nio_fs_AixNativeDispatcher_getmntctl()
In-Reply-To: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
References: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
Message-ID: <4ud5HEzi5w3K5OKQWxXzVnMPiVEafbbOBqw2j-wJHdM=.00ec7f5b-43de-4fd9-84d0-3e8afee7710c@github.com>

On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory).

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16151#pullrequestreview-1671538361

From brian.burkhalter at oracle.com  Wed Oct 11 15:54:44 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 Oct 2023 15:54:44 +0000
Subject: [Request for Comments] File extension redux
In-Reply-To: <f869318d-8ad2-e17e-84fc-54e9fb7ba1bf@oracle.com>
References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com>
 <f869318d-8ad2-e17e-84fc-54e9fb7ba1bf@oracle.com>
Message-ID: <D826E292-3DAB-454A-85F1-93FCCD64A9FD@oracle.com>

Hi Roger,

Thanks for the detailed, prompt response. It appears that what I have been thinking is pretty much in line with what you wrote. Specifically I have been considering the following proposal:


  *   In the common case, the extension is the sequence of characters after the last period character in the file name.
  *   The extension does not include the period character.
  *   An indeterminate extension is represented by the empty string ??; no nulls.
  *   Three methods could be added to Path:
     *   String getExtension()
     *   Path removeExtension()
     *   Path addExtension(String)
  *   For a given Path p this invariant would be satisfied:
     *   p.equals(p.removeExtension().addExtension(p.getExtension())) == true

The foregoing approach would, I think, obviate the need to directly handle the period character.

Thanks,

Brian

On Oct 10, 2023, at 2:31 PM, Roger Riggs <Roger.Riggs at oracle.com<mailto:Roger.Riggs at oracle.com>> wrote:

Hi Brian,

First the intuition and then the rationale.

Intuition: the extension does not include the period '.' learned from years of working with existing systems, both shell and programming languages with file apis.

Second: In trying to make Path.getExtension() handle all of the use cases possible, it makes some of them more difficult.  In particular, the cases for removing or replacing the extension are easier to do with a method for that purpose. It is easier to explain using a Path.removeExtension() method than to explain how to convert the path to a string and then remove some number of characters from the end and recreate the Path.

Rationale:

  *   Other Java libraries that provide path name utilities do not include the dot as part of the extension; (Guava and Apache Commons). A mismatch with them (and other common Java libraries) creates friction and room to make mistakes in conversions between different representations.
  *   The no-dot representation works just fine except in the case of trailing dot, which is quite uncommon in practice.
  *   The APIs provided should do what the programmer needs to do, not be APIs from which the programmer can create the API they need and still avoid an explosion of APIs for narrow use cases.
  *   Extensions are used in many ways, from switch statements to keys in maps to simple if/then/else; some are hard coded and others are configured or loaded as plugins. The semantics should be simple and direct.

For 1) and 3) I would say that both "foo" or "foo." have an empty ("") extension.
Providing a removeExtension() or replaceExtension(String) method can embed the edge case handling and make the API easy to use without having to burden the Path.getExtension() method with a model that includes that complexity.

Regards, Roger


On 10/10/23 2:31 PM, Brian Burkhalter wrote:
I would like to resurrect this topic which has languished for quite a while now. It was discussed for probably decades before my involvement with it. A brief outline of its most recent history is included below. The essence is that it would be good to add a java.nio.file.Path.getExtension method, and possibly one or more companion methods. General comments on the topic are welcome regardless of whether the included chronology is reviewed. Things to consider include:

1) whether a getExtension method ever returns null;
2) whether a period character is included as the first character of the returned extension;
3) whether the extension of ?foo? (no dot) differs from that of ?foo.? (terminal dot).

Thanks,

Brian

--- snip --- TL;DR --- snip ---

[1] Feb. 2018
Path.hasExtension was initially proposed but dropped in favor of Path.getExtension. This method was for the most common cases equivalent to

Path path = ...;
String name = path.getFileName();
String extension = name.substring(name.lastIndexOf(?.?) + 1);

which is to say the extension is the portion of the file name string after but not including the last period character (dot). This effort faded out.

[2] Apr. 2021 - Mar. 2022
A pull request was proposed and culminated in the proposal of the Path method

String getExtension(String defaultExtension)

where in the common case the extension is once again the portion of the file name string after the last dot. For degenerate cases the ?defaultExtension? parameter would be returned.  This effort was superseded by [3].

[3] Mar. 2022 - Dec. 2022

This pull request specified the Path method

String getExtension()

which in the common case returned the portion of the file name string after the last dot, and in unusual cases either the empty string (terminal dot) or null (no dot). For a time this proposal used Optional but that was dropped as unwieldy. This PR was approved and integrated.

[4] Dec. 2022

Due primarily to the undesirability of the possibility of a null return value and the lateness of the integration in the development cycle, the API added in [3] was backed out.

[5] Dec. 22

A new issue was filed to track the resumption of eventual work on this topic. This issue suggested that the last dot be included in the extension, e.g., the extension of ?image.jpg? would be ?.jpg? rather than ?jpg? and that the value returned by getExtension would never be null. It also proposed a complementary method Path.removeExtension which, together with Path.getExtension, would form an invariant

Path path = ...;
assert path.equals(path.removeExtension() + path.getExtension());

which would obviate the need to handle a period character explicitly.

[1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html
[2] https://github.com/openjdk/jdk/pull/2319
[3] https://github.com/openjdk/jdk/pull/8066
[4] https://github.com/openjdk/jdk/pull/11566
[5] https://bugs.openjdk.org/browse/JDK-8298318


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

From dfuchs at openjdk.org  Wed Oct 11 16:40:23 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Oct 2023 16:40:23 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <OijHB1TVVmIeCUpk7wxH3pUjWN9MhLPkaK4LID4CAk0=.b4a4136c-1ef9-4636-b597-04dfd899183c@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1671817764

From iris at openjdk.org  Wed Oct 11 16:40:24 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 11 Oct 2023 16:40:24 GMT
Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer
In-Reply-To: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
References: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
Message-ID: <w7FgRnIdAFt5iF_1K_MilmMkMNvRAsuUdEfTDudoRso=.df01fcd4-3d76-4df8-8ff0-30c47f46b946@github.com>

On Wed, 11 Oct 2023 08:59:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to Add @sealedGraph to `ByteBuffer`.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16142#pullrequestreview-1671798420

From david.lloyd at redhat.com  Wed Oct 11 16:50:33 2023
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 11 Oct 2023 11:50:33 -0500
Subject: [Request for Comments] File extension redux
In-Reply-To: <D826E292-3DAB-454A-85F1-93FCCD64A9FD@oracle.com>
References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com>
 <f869318d-8ad2-e17e-84fc-54e9fb7ba1bf@oracle.com>
 <D826E292-3DAB-454A-85F1-93FCCD64A9FD@oracle.com>
Message-ID: <CANghgrTDEvdXii5q_XEJJa66JHJ8_3bbM02+CQwmAkLwJOPeZw@mail.gmail.com>

For the edge case where the file ends in, /or/ comprises, a solitary `.`,
would `removeExtension()` remove the `.` and `addExtension("")` add it
back, or would both methods leave the path unaffected (either one would
satisfy the invariant)? Or some other behavior?

On Wed, Oct 11, 2023 at 10:56?AM Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Hi Roger,
>
> Thanks for the detailed, prompt response. It appears that what I have been
> thinking is pretty much in line with what you wrote. Specifically I have
> been considering the following proposal:
>
>
>    - In the common case, the extension is the sequence of characters
>    after the last period character in the file name.
>    - The extension does *not* include the period character.
>    - An indeterminate extension is represented by the empty string ??; no
>    nulls.
>    - Three methods could be added to Path:
>       - String getExtension()
>       - Path removeExtension()
>       - Path addExtension(String)
>    - For a given Path p this invariant would be satisfied:
>       - p.equals(p.removeExtension().addExtension(p.getExtension())) ==
>       true
>
>
> The foregoing approach would, I think, obviate the need to directly handle
> the period character.
>
> Thanks,
>
> Brian
>
> On Oct 10, 2023, at 2:31 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
> Hi Brian,
>
> First the intuition and then the rationale.
>
> Intuition: the extension does not include the period '.' learned from
> years of working with existing systems, both shell and programming
> languages with file apis.
>
> Second: In trying to make Path.getExtension() handle all of the use cases
> possible, it makes some of them more difficult.  In particular, the cases
> for removing or replacing the extension are easier to do with a method for
> that purpose. It is easier to explain using a Path.removeExtension() method
> than to explain how to convert the path to a string and then remove some
> number of characters from the end and recreate the Path.
>
> Rationale:
>
>    - Other Java libraries that provide path name utilities do not include
>    the dot as part of the extension; (Guava and Apache Commons). A mismatch
>    with them (and other common Java libraries) creates friction and room to
>    make mistakes in conversions between different representations.
>    - The no-dot representation works just fine except in the case of
>    trailing dot, which is quite uncommon in practice.
>    - The APIs provided should do what the programmer needs to do, not be
>    APIs from which the programmer can create the API they need and still avoid
>    an explosion of APIs for narrow use cases.
>    - Extensions are used in many ways, from switch statements to keys in
>    maps to simple if/then/else; some are hard coded and others are configured
>    or loaded as plugins. The semantics should be simple and direct.
>
> For 1) and 3) I would say that both "foo" or "foo." have an empty ("")
> extension.
> Providing a removeExtension() or replaceExtension(String) method can embed
> the edge case handling and make the API easy to use without having to
> burden the Path.getExtension() method with a model that includes that
> complexity.
>
> Regards, Roger
>
>
> On 10/10/23 2:31 PM, Brian Burkhalter wrote:
>
> I would like to resurrect this topic which has languished for quite a
> while now. It was discussed for probably decades before my involvement with
> it. A brief outline of its most recent history is included below. The
> essence is that it would be good to add a java.nio.file.Path.getExtension
> method, and possibly one or more companion methods. General comments on the
> topic are welcome regardless of whether the included chronology is
> reviewed. Things to consider include:
>
> 1) whether a getExtension method ever returns null;
> 2) whether a period character is included as the first character of the
> returned extension;
> 3) whether the extension of ?foo? (no dot) differs from that of ?foo.?
> (terminal dot).
>
> Thanks,
>
> Brian
>
> --- snip --- TL;DR --- snip ---
>
> [1] Feb. 2018
> Path.hasExtension was initially proposed but dropped in favor of
> Path.getExtension. This method was for the most common cases equivalent to
>
> Path path = ...;
> String name = path.getFileName();
> String extension = name.substring(name.lastIndexOf(?.?) + 1);
>
> which is to say the extension is the portion of the file name string after
> but not including the last period character (dot). This effort faded out.
>
> [2] Apr. 2021 - Mar. 2022
> A pull request was proposed and culminated in the proposal of the Path
> method
>
> String getExtension(String defaultExtension)
>
> where in the common case the extension is once again the portion of the
> file name string after the last dot. For degenerate cases the
> ?defaultExtension? parameter would be returned.  This effort was superseded
> by [3].
>
> [3] Mar. 2022 - Dec. 2022
>
> This pull request specified the Path method
>
> String getExtension()
>
> which in the common case returned the portion of the file name string
> after the last dot, and in unusual cases either the empty string (terminal
> dot) or null (no dot). For a time this proposal used Optional but that was
> dropped as unwieldy. This PR was approved and integrated.
>
> [4] Dec. 2022
>
> Due primarily to the undesirability of the possibility of a null return
> value and the lateness of the integration in the development cycle, the API
> added in [3] was backed out.
>
> [5] Dec. 22
>
> A new issue was filed to track the resumption of eventual work on this
> topic. This issue suggested that the last dot be included in the extension,
> e.g., the extension of ?image.jpg? would be ?.jpg? rather than ?jpg? and
> that the value returned by getExtension would never be null. It also
> proposed a complementary method Path.removeExtension which, together with
> Path.getExtension, would form an invariant
>
> Path path = ...;
> assert path.equals(path.removeExtension() + path.getExtension());
>
> which would obviate the need to handle a period character explicitly.
>
> [1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html
> [2] https://github.com/openjdk/jdk/pull/2319
> [3] https://github.com/openjdk/jdk/pull/8066
> [4] https://github.com/openjdk/jdk/pull/11566
> [5] https://bugs.openjdk.org/browse/JDK-8298318
>
>
>
>

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20231011/85180d84/attachment-0001.htm>

From brian.burkhalter at oracle.com  Wed Oct 11 16:55:13 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 Oct 2023 16:55:13 +0000
Subject: [Request for Comments] File extension redux
In-Reply-To: <CANghgrTDEvdXii5q_XEJJa66JHJ8_3bbM02+CQwmAkLwJOPeZw@mail.gmail.com>
References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com>
 <f869318d-8ad2-e17e-84fc-54e9fb7ba1bf@oracle.com>
 <D826E292-3DAB-454A-85F1-93FCCD64A9FD@oracle.com>
 <CANghgrTDEvdXii5q_XEJJa66JHJ8_3bbM02+CQwmAkLwJOPeZw@mail.gmail.com>
Message-ID: <BB3D708F-0B3D-4A39-AB8F-B99E3F27CA6F@oracle.com>

I?ve not gone through 100% of the edge cases, but for this one I would think both add and remove would not affect ?.? or ?foo.?.

Brian

On Oct 11, 2023, at 9:50 AM, David Lloyd <david.lloyd at redhat.com<mailto:david.lloyd at redhat.com>> wrote:

For the edge case where the file ends in, /or/ comprises, a solitary `.`, would `removeExtension()` remove the `.` and `addExtension("")` add it back, or would both methods leave the path unaffected (either one would satisfy the invariant)? Or some other behavior?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20231011/4a0e0b20/attachment.htm>

From vtewari at openjdk.org  Wed Oct 11 17:38:26 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 11 Oct 2023 17:38:26 GMT
Subject: RFR: JDK-8038244: (fs) Check return value of malloc in
 Java_sun_nio_fs_AixNativeDispatcher_getmntctl()
In-Reply-To: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
References: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
Message-ID: <fqkB2LNsrhFpKWg6vJpQ5BHwzYnsKdiWK30fwBINbUg=.174074cf-7176-4a30-9c57-f291a20c3c44@github.com>

On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory).

Looks OK to me.

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16151#pullrequestreview-1672038075

From rriggs at openjdk.org  Wed Oct 11 18:16:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Oct 2023 18:16:04 GMT
Subject: RFR: JDK-8038244: (fs) Check return value of malloc in
 Java_sun_nio_fs_AixNativeDispatcher_getmntctl()
In-Reply-To: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
References: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
Message-ID: <-w1QkL31nOamtv83AzXtGv3kmKkDk-JhTJtv2ItcP9Q=.cb25ebf5-1432-4587-93a3-721dba04afcf@github.com>

On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory).

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16151#pullrequestreview-1672174030

From roger.riggs at oracle.com  Wed Oct 11 18:33:33 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 11 Oct 2023 14:33:33 -0400
Subject: [Request for Comments] File extension redux
In-Reply-To: <BB3D708F-0B3D-4A39-AB8F-B99E3F27CA6F@oracle.com>
References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com>
 <f869318d-8ad2-e17e-84fc-54e9fb7ba1bf@oracle.com>
 <D826E292-3DAB-454A-85F1-93FCCD64A9FD@oracle.com>
 <CANghgrTDEvdXii5q_XEJJa66JHJ8_3bbM02+CQwmAkLwJOPeZw@mail.gmail.com>
 <BB3D708F-0B3D-4A39-AB8F-B99E3F27CA6F@oracle.com>
Message-ID: <6c5da012-faf5-ffbb-51e2-5bae2cbcf8d3@oracle.com>

Hi,

Typically a leading "." (for the directories "." and "..") would not be 
considered the start of an extension.? (As was spec'd earlier). Both 
"/." and "/.." have an empty extension.

I would suggest that `removeExtension()` would be more useful if it 
removed the final ".", if any.
`addExtension("txt")` would be smart enough to handle both "abc." and 
"abc" resulting in "abc.txt".

$.02, Roger

On 10/11/23 12:55 PM, Brian Burkhalter wrote:
> I?ve not gone through 100% of the edge cases, but for this one I would 
> think both add and remove would not affect ?.? or ?foo.?.
>
> Brian
>
>> On Oct 11, 2023, at 9:50 AM, David Lloyd <david.lloyd at redhat.com> wrote:
>>
>> For the edge case where the file ends in, /or/ comprises, a solitary 
>> `.`, would `removeExtension()` remove?the `.` and `addExtension("")` 
>> add it back, or would both methods leave the path unaffected (either 
>> one would satisfy the invariant)? Or some other behavior?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20231011/d72a367a/attachment-0001.htm>

From brian.burkhalter at oracle.com  Wed Oct 11 18:39:39 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 Oct 2023 18:39:39 +0000
Subject: [Request for Comments] File extension redux
In-Reply-To: <6c5da012-faf5-ffbb-51e2-5bae2cbcf8d3@oracle.com>
References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com>
 <f869318d-8ad2-e17e-84fc-54e9fb7ba1bf@oracle.com>
 <D826E292-3DAB-454A-85F1-93FCCD64A9FD@oracle.com>
 <CANghgrTDEvdXii5q_XEJJa66JHJ8_3bbM02+CQwmAkLwJOPeZw@mail.gmail.com>
 <BB3D708F-0B3D-4A39-AB8F-B99E3F27CA6F@oracle.com>
 <6c5da012-faf5-ffbb-51e2-5bae2cbcf8d3@oracle.com>
Message-ID: <781CA0B6-08FA-4421-83BB-F74ED9E38F2C@oracle.com>


On Oct 11, 2023, at 11:33 AM, Roger Riggs <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com>> wrote:

Typically a leading "." (for the directories "." and "..") would not be considered the start of an extension.  (As was spec'd earlier).  Both "/." and "/.." have an empty extension.

Agreed.

I would suggest that `removeExtension()` would be more useful if it removed the final ".", if any.
`addExtension("txt")` would be smart enough to handle both "abc." and "abc" resulting in "abc.txt?.

I think that would work.

Aside from ?.?, ?..?, a leading ?.? to denote hidden files on UNIX, and various edge cases to be ignored for the moment, I look at the ?.? as a separator character somewhat analogous to File.separatorChar.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20231011/e9b74990/attachment.htm>

From mbaesken at openjdk.org  Thu Oct 12 07:19:22 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 07:19:22 GMT
Subject: RFR: JDK-8038244: (fs) Check return value of malloc in
 Java_sun_nio_fs_AixNativeDispatcher_getmntctl()
In-Reply-To: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
References: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
Message-ID: <CQy5ms909FTuyQ7y_qhMQeKZHhB6QQXbqibX6J9l8XE=.1d5cd4cc-db5e-4538-8f9d-7a5d63c04db8@github.com>

On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory).

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/16151#issuecomment-1759063686

From mbaesken at openjdk.org  Thu Oct 12 07:19:23 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 07:19:23 GMT
Subject: Integrated: JDK-8038244: (fs) Check return value of malloc in
 Java_sun_nio_fs_AixNativeDispatcher_getmntctl()
In-Reply-To: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
References: <dB2wnPmSNOKdvhxwIVoZ-ZrxRNjYHb1DZYZAMGMnKS8=.4bdff088-95bc-416e-bcb1-fe71aedb84ad@github.com>
Message-ID: <Twtw8EOVZLvslc4eAfmMEX3P-v57F-dwjSjPXxp78Is=.81ad8560-9e53-4352-afbb-c860ca7ce511@github.com>

On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory).

This pull request has now been integrated.

Changeset: 6d6c9008
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d6c9008d5c87631771e194f475b14e178d16322
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8038244: (fs) Check return value of malloc in Java_sun_nio_fs_AixNativeDispatcher_getmntctl()

Reviewed-by: bpb, vtewari, rriggs

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

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

From mbaesken at openjdk.org  Thu Oct 12 07:25:23 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 07:25:23 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <2LvAHcncM4Kz_4yLH4KfixikvW2sV087KwHsJnsSKCc=.cf19c19b-ffa0-4806-9d84-cb6f373edca5@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

Hi Daniel and Alan, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/16139#issuecomment-1759071633

From mbaesken at openjdk.org  Thu Oct 12 07:25:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 07:25:25 GMT
Subject: Integrated: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <fMY7ZqSD1-jPkWvncEhQRaQbV1nad6q1qlKMZtuel4o=.9a3062ce-bb95-4668-a532-c22c4efdb77d@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

This pull request has now been integrated.

Changeset: 424de295
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/424de295a6ca19e9aacb7e1e1c9b5f955064cb65
Stats:     34 lines in 4 files changed: 4 ins; 27 del; 3 mod

8317866: replace NET_SocketAvailable

Reviewed-by: dfuchs, alanb

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

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

From mbaesken at openjdk.org  Thu Oct 12 08:09:44 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 08:09:44 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native java.base
 coding
Message-ID: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>

There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.

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

Commit messages:
 - JDK-8317959

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

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

From alanb at openjdk.org  Thu Oct 12 13:02:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 13:02:55 GMT
Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer
In-Reply-To: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
References: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
Message-ID: <Y9zBV1kMxDBND57kuTHpf5P-nef-MV1JvnzdjYQpHZ0=.466b7e3d-b27a-4eed-b514-469280d6d4f7@github.com>

On Wed, 11 Oct 2023 08:59:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to Add @sealedGraph to `ByteBuffer`.

Would it possible to include an image on how this looks? Asking because Buffer already has sealedGraph so shows the hierarchy. For ByteBuffer then presumably it will just show that MBB extends BB so I'm wondering if it's useful or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/16142#issuecomment-1759462766

From alanb at openjdk.org  Thu Oct 12 13:04:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 13:04:18 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS [v2]
In-Reply-To: <ZtFZM_QcMAREdC0NBSScQSddt9UV9CgDYv72AqTf10s=.48408e3e-4a83-4106-8339-3d41520266ad@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
 <ZtFZM_QcMAREdC0NBSScQSddt9UV9CgDYv72AqTf10s=.48408e3e-4a83-4106-8339-3d41520266ad@github.com>
Message-ID: <_ejoUp3sp4K0v5lAOJcfVT-zpBeIS23Ivhv0c3a8L-8=.ef3788d6-57d7-4450-b141-f3c56da43297@github.com>

On Mon, 9 Oct 2023 19:00:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317687: Return false for "unix" view of FAT

Marked as reviewed by alanb (Reviewer).

src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 106:

> 104:         // POSIX attributes not supported on FAT
> 105:         if (type == PosixFileAttributeView.class &&
> 106:             entry().fstype().equals("msdos"))

The check would be easier to read if it were on one line.

BTW: Shouldn't this say "FAT32" rather than "FAT"?

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

PR Review: https://git.openjdk.org/jdk/pull/16084#pullrequestreview-1674005323
PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1356729152

From alanb at openjdk.org  Thu Oct 12 13:07:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 13:07:48 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <mZJG405OGCCOoErDvTWUzvuGHCh1RANxV6ihIf3qfeM=.bec16d07-b069-43ee-bddf-305430e460f4@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Changes in this area only require one reviewer so it's okay to integrate if you want.

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

PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759495468

From pminborg at openjdk.org  Thu Oct 12 13:54:33 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Oct 2023 13:54:33 GMT
Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer
In-Reply-To: <Y9zBV1kMxDBND57kuTHpf5P-nef-MV1JvnzdjYQpHZ0=.466b7e3d-b27a-4eed-b514-469280d6d4f7@github.com>
References: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
 <Y9zBV1kMxDBND57kuTHpf5P-nef-MV1JvnzdjYQpHZ0=.466b7e3d-b27a-4eed-b514-469280d6d4f7@github.com>
Message-ID: <JBzXwA1QlIlI1-pfhBVoIa4nHq1zkt59LBWVk2J4gUs=.4c83d40b-732a-40fc-a738-12781bb714c9@github.com>

On Thu, 12 Oct 2023 11:54:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it possible to include an image on how this looks? Asking because Buffer already has sealedGraph so shows the hierarchy. For ByteBuffer then presumably it will just show that MBB extends BB so I'm wondering if it's useful or not.

As you say, `Buffer` already has the tag, and because of that the JavaDoc of the class will include a graph:

<img width="1195" alt="image" src="https://github.com/openjdk/jdk/assets/7457876/dc31c0c2-3c89-4ab2-920e-f25a6cfbb441">

However, the tag works on a per-class basis and is not transitive. So ByteBuffer will not have a graph even though it and its permitted subclass MBB is rendered for the `Buffer` class.

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

PR Comment: https://git.openjdk.org/jdk/pull/16142#issuecomment-1759573618

From alanb at openjdk.org  Thu Oct 12 13:54:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 13:54:33 GMT
Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer
In-Reply-To: <JBzXwA1QlIlI1-pfhBVoIa4nHq1zkt59LBWVk2J4gUs=.4c83d40b-732a-40fc-a738-12781bb714c9@github.com>
References: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
 <Y9zBV1kMxDBND57kuTHpf5P-nef-MV1JvnzdjYQpHZ0=.466b7e3d-b27a-4eed-b514-469280d6d4f7@github.com>
 <JBzXwA1QlIlI1-pfhBVoIa4nHq1zkt59LBWVk2J4gUs=.4c83d40b-732a-40fc-a738-12781bb714c9@github.com>
Message-ID: <gLVX_igB_vkPMBKxXLr6Q_qQqAwb1B1Sygn8yjAa5VA=.91baaa4b-3ec8-4212-adb0-ffe879ad40f6@github.com>

On Thu, 12 Oct 2023 13:03:53 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> However, the tag works on a per-class basis and is not transitive. So ByteBuffer will not have a graph even though it and its permitted subclass MBB is rendered for the `Buffer` class.

It works well in Buffer as there is a hierarchy to show. It seems a bit confusing to me to have it also show up in the ByteBuffer docs. Have I missed something or what is the reason for doing this?

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

PR Comment: https://git.openjdk.org/jdk/pull/16142#issuecomment-1759603209

From dfuchs at openjdk.org  Thu Oct 12 14:02:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Oct 2023 14:02:04 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <Z95zxmawwZ75gFm0AYzrOs8sss07-NBokjjNxUPScJw=.5dd45b54-794e-44a3-8e24-2af5d6908ddb@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

LGTM - I was expecting @tprinzing to review too, but yes you can integrate if you want.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15908#pullrequestreview-1674252334

From mbaesken at openjdk.org  Thu Oct 12 14:16:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 14:16:55 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
References: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
Message-ID: <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>

> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.

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

  doabort in check method in case no memory can be allocated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16160/files
  - new: https://git.openjdk.org/jdk/pull/16160/files/24fbb465..109b13c3

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

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

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

From alanb at openjdk.org  Thu Oct 12 14:16:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 14:16:57 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
References: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
 <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
Message-ID: <B3FxGu7LkMH6tlQdOUqxnGvG-b1WZ_sGicxEWLw2E-k=.7b3677eb-7a04-4301-a8e8-4c580409e5bc@github.com>

On Thu, 12 Oct 2023 12:17:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doabort in check method in case no memory can be allocated

src/java.base/windows/native/libjli/cmdtoargs.c line 327:

> 325:         // "pgmname" rest of cmdline ie. pgmname + 2 double quotes + space + cmdline from windows
> 326:         char* cptr = (char*) malloc(strlen(argv[0]) + sizeof(char) * 3 + strlen(cmdline) + 1);
> 327:         if (cptr == NULL) return false;

This doesn't look right, I think it has no choice but to print an error and doabort..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16160#discussion_r1356709874

From mbaesken at openjdk.org  Thu Oct 12 14:16:57 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 14:16:57 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: <B3FxGu7LkMH6tlQdOUqxnGvG-b1WZ_sGicxEWLw2E-k=.7b3677eb-7a04-4301-a8e8-4c580409e5bc@github.com>
References: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
 <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
 <B3FxGu7LkMH6tlQdOUqxnGvG-b1WZ_sGicxEWLw2E-k=.7b3677eb-7a04-4301-a8e8-4c580409e5bc@github.com>
Message-ID: <EVgiT2YkUu04WaHgfIBO0eY2VdFzUf2vJ4wMVN9iVug=.67900d42-74f7-453d-86c3-03c0aa85dce7@github.com>

On Thu, 12 Oct 2023 12:00:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   doabort in check method in case no memory can be allocated
>
> src/java.base/windows/native/libjli/cmdtoargs.c line 327:
> 
>> 325:         // "pgmname" rest of cmdline ie. pgmname + 2 double quotes + space + cmdline from windows
>> 326:         char* cptr = (char*) malloc(strlen(argv[0]) + sizeof(char) * 3 + strlen(cmdline) + 1);
>> 327:         if (cptr == NULL) return false;
> 
> This doesn't look right, I think it has no choice but to print an error and doabort..

Hi Alan, I adjusted this part of the coding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16160#discussion_r1356728099

From tprinzing at openjdk.org  Thu Oct 12 14:47:38 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 12 Oct 2023 14:47:38 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <UT31A_j03xq6DCG7IBBxfPEZ18I13iGCkHvzuJx5o9U=.2660ea5c-916b-4a46-90d2-dc6ca164d067@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

I was planning to change the convenience function to take functions as arguments.  With this change there is a bunch of duplicated code.

I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759755174

From bpb at openjdk.org  Thu Oct 12 15:17:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Oct 2023 15:17:36 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS [v2]
In-Reply-To: <_ejoUp3sp4K0v5lAOJcfVT-zpBeIS23Ivhv0c3a8L-8=.ef3788d6-57d7-4450-b141-f3c56da43297@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
 <ZtFZM_QcMAREdC0NBSScQSddt9UV9CgDYv72AqTf10s=.48408e3e-4a83-4106-8339-3d41520266ad@github.com>
 <_ejoUp3sp4K0v5lAOJcfVT-zpBeIS23Ivhv0c3a8L-8=.ef3788d6-57d7-4450-b141-f3c56da43297@github.com>
Message-ID: <opb7tiQ66vIN7T-BjvO4A6SMFKbv_OR6AZ1WNQvuVxI=.1b83054d-1261-4759-88a6-5f0d784dfd83@github.com>

On Thu, 12 Oct 2023 12:18: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:
>> 
>>   8317687: Return false for "unix" view of FAT
>
> src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 106:
> 
>> 104:         // POSIX attributes not supported on FAT
>> 105:         if (type == PosixFileAttributeView.class &&
>> 106:             entry().fstype().equals("msdos"))
> 
> The check would be easier to read if it were on one line.
> 
> BTW: Shouldn't this say "FAT32" rather than "FAT"?

Yes. Same story in `LinuxFileStore`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1356982609

From bpb at openjdk.org  Thu Oct 12 15:38:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Oct 2023 15:38:40 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS [v3]
In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
Message-ID: <-v-gPQBDAixxoIr7bYBvzwprj7I_FFzQKf47Onu-swI=.c4551bfb-ea19-478e-995c-a08772eca289@github.com>

> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32.

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

  8317687: /FAT/FAT32/ in comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16084/files
  - new: https://git.openjdk.org/jdk/pull/16084/files/0cc942c2..853caa1b

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

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

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

From bpb at openjdk.org  Thu Oct 12 15:38:42 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Oct 2023 15:38:42 GMT
Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS [v2]
In-Reply-To: <opb7tiQ66vIN7T-BjvO4A6SMFKbv_OR6AZ1WNQvuVxI=.1b83054d-1261-4759-88a6-5f0d784dfd83@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
 <ZtFZM_QcMAREdC0NBSScQSddt9UV9CgDYv72AqTf10s=.48408e3e-4a83-4106-8339-3d41520266ad@github.com>
 <_ejoUp3sp4K0v5lAOJcfVT-zpBeIS23Ivhv0c3a8L-8=.ef3788d6-57d7-4450-b141-f3c56da43297@github.com>
 <opb7tiQ66vIN7T-BjvO4A6SMFKbv_OR6AZ1WNQvuVxI=.1b83054d-1261-4759-88a6-5f0d784dfd83@github.com>
Message-ID: <qKlyy2fW4ZQYb5_FMy_Ld5xC1uCAe4ygVPPckDvcf4c=.bd0efee6-b302-4f52-99be-16a7df54f2dd@github.com>

On Thu, 12 Oct 2023 15:15:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 106:
>> 
>>> 104:         // POSIX attributes not supported on FAT
>>> 105:         if (type == PosixFileAttributeView.class &&
>>> 106:             entry().fstype().equals("msdos"))
>> 
>> The check would be easier to read if it were on one line.
>> 
>> BTW: Shouldn't this say "FAT32" rather than "FAT"?
>
> Yes. Same story in `LinuxFileStore`.

Comments so change in 853caa1b4b3360c5026b0c6df11c61825234a302.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1357012113

From egahlin at openjdk.org  Thu Oct 12 15:51:28 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 12 Oct 2023 15:51:28 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <5CpsTt095Fp76yWPbqfYuiWBqB5HoJPyTIhkNifUBP8=.73812635-fefd-4fd3-8366-484bb9e0c0c6@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

> I was planning to change the convenience function to take functions as arguments. With this change there is a bunch of duplicated code.
> 
> I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this.



> I was planning to change the convenience function to take functions as arguments. With this change there is a bunch of duplicated code.
> 
> I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this.

If it's a lambda, it could be problematic. I have another change coming up, which also motivated this PR. It's still in draft, need to decide on the syntax, but it adds an annotation that can filter out stack frames, for example the emit() method. A lambda wouldn't get a proper method name.

https://github.com/openjdk/jdk/pull/15867

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

PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759888327

From alanb at openjdk.org  Thu Oct 12 16:24:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 16:24:12 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
References: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
 <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
Message-ID: <bgUfiiu9kG5isHZW3h4NawHscjqmOVWkDZo0DaDD1Og=.10853676-86b1-42f1-8380-1c04bee4e543@github.com>

On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doabort in check method in case no memory can be allocated

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16160#pullrequestreview-1674603470

From bpb at openjdk.org  Thu Oct 12 16:49:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Oct 2023 16:49:15 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
References: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
 <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
Message-ID: <pp0xHiUiWm9mg4NgrCigJ0lTncjcg0GJRqxVGt_qXcU=.30439cdc-8b34-4981-bf3e-2ed71a3905c5@github.com>

On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doabort in check method in case no memory can be allocated

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16160#pullrequestreview-1674660076

From bpb at openjdk.org  Thu Oct 12 19:21:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Oct 2023 19:21:20 GMT
Subject: RFR: 8312527: (api) Re-examine use of
 sun.nio.ch.Invoker.myGroupAndInvokeCount
Message-ID: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>

Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`.

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

Commit messages:
 - 8312527: (api) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount

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

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

From bpb at openjdk.org  Thu Oct 12 19:21:21 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Oct 2023 19:21:21 GMT
Subject: RFR: 8312527: (api) Re-examine use of
 sun.nio.ch.Invoker.myGroupAndInvokeCount
In-Reply-To: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>
References: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>
Message-ID: <TdteOSsR_l8IGMtefCLgV3md-3UmSMwqX0PY0F5QiAc=.602ea5f8-178d-4678-829d-852a768a911c@github.com>

On Thu, 12 Oct 2023 19:13:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`.

The anonymous class overrides `initialValue()` identically to how it is defined in `ThreadLocal` itself.

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

PR Comment: https://git.openjdk.org/jdk/pull/16170#issuecomment-1760229250

From jvernee at openjdk.org  Thu Oct 12 19:53:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Oct 2023 19:53:54 GMT
Subject: Integrated: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <iRztDEMFM6qVS37tplOdcCwF6X13yX7GpGZumCh5T1M=.a13eaa79-8eb2-4f74-8be5-670b3658906e@github.com>

On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

This pull request has now been integrated.

Changeset: 32ac72c3
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32ac72c3d35138f5253e4defc948304ac3ea1b53
Stats:     4468 lines in 263 files changed: 2211 ins; 1196 del; 1061 mod

8312522: Implementation of Foreign Function & Memory API

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Per Minborg <pminborg at openjdk.org>
Reviewed-by: dholmes, psandoz, mcimadamore, alanb

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

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

From duke at openjdk.org  Fri Oct 13 03:30:49 2023
From: duke at openjdk.org (xpbob)
Date: Fri, 13 Oct 2023 03:30:49 GMT
Subject: RFR: 8318058: Notify the jvm when the direct memory is oom
Message-ID: <c3tlbNBprc7M5j89f1tB498ICCMX64PNyvilpzkkFjA=.2b33fd0f-fbe5-4e26-81ed-d6638b765edd@github.com>

Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod

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

Commit messages:
 - 8318058: Notify the jvm when the direct memory is oom

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

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

From stuefe at openjdk.org  Fri Oct 13 05:29:14 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Oct 2023 05:29:14 GMT
Subject: RFR: 8318058: Notify the jvm when the direct memory is oom
In-Reply-To: <c3tlbNBprc7M5j89f1tB498ICCMX64PNyvilpzkkFjA=.2b33fd0f-fbe5-4e26-81ed-d6638b765edd@github.com>
References: <c3tlbNBprc7M5j89f1tB498ICCMX64PNyvilpzkkFjA=.2b33fd0f-fbe5-4e26-81ed-d6638b765edd@github.com>
Message-ID: <yVZKJQ5xkAqHGKfnbHgLLtbhFN5OhYPWYSGwpsg_cfQ=.b0ededba-0b03-4f5f-80fc-a0f2e8740b4e@github.com>

On Fri, 13 Oct 2023 03:23:04 GMT, xpbob <duke at openjdk.org> wrote:

> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod

Undoubtedly useful, but there have been many discussions in the past about what does and does not constitute an OOM error, and IIRC, the stance of Oracle devs was "only if it is in java heap". Hence the missing OOM error when we cannot create threads, for instance.

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

PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1760881555

From alanb at openjdk.org  Fri Oct 13 06:13:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Oct 2023 06:13:21 GMT
Subject: RFR: 8318058: Notify the jvm when the direct memory is oom
In-Reply-To: <c3tlbNBprc7M5j89f1tB498ICCMX64PNyvilpzkkFjA=.2b33fd0f-fbe5-4e26-81ed-d6638b765edd@github.com>
References: <c3tlbNBprc7M5j89f1tB498ICCMX64PNyvilpzkkFjA=.2b33fd0f-fbe5-4e26-81ed-d6638b765edd@github.com>
Message-ID: <k4S_hHIWxtq_fYdmwT4E0lbmlIK5QhAMp79u7H6F9bc=.7182d19f-3b6d-4996-ba43-fe9de3a7aac6@github.com>

On Fri, 13 Oct 2023 03:23:04 GMT, xpbob <duke at openjdk.org> wrote:

> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod

JDK-8294052 has some of the previous discussion on this issue.

See also this thread where Man, Thomas, David and I discussed the topic:
https://mail.openjdk.org/pipermail/nio-dev/2022-September/012119.html

There were previous threads on the same topic, I can't find the links right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1760950115

From alanb at openjdk.org  Fri Oct 13 06:25:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Oct 2023 06:25:20 GMT
Subject: RFR: 8312527: (ch) Re-examine use of
 sun.nio.ch.Invoker.myGroupAndInvokeCount
In-Reply-To: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>
References: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>
Message-ID: <mtk1fOKqFW4sN5YIuL6gbGJ7k7YVDDG_yohVUnmUopI=.3193f34a-be0e-4432-9a06-f440679c768e@github.com>

On Thu, 12 Oct 2023 19:13:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`.

No need to override initialValue so I think this cleanup looks okay,

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16170#pullrequestreview-1675792412

From mbaesken at openjdk.org  Fri Oct 13 06:53:34 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Oct 2023 06:53:34 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
References: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
 <QQHTOkn6QGqr-Wj5rgIKAgq2vZ_As2yjvtulqXHk8Ks=.ce47fc10-5da1-47f9-849d-a243021431f0@github.com>
Message-ID: <xzoW20BDAwIoXgZLkTaEGx-Pb8RQbpkITsTCupcadZM=.d24f6352-01df-4b66-a4cb-f41fe2ebb22b@github.com>

On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doabort in check method in case no memory can be allocated

Hi Alan and Brian, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/16160#issuecomment-1760994212

From mbaesken at openjdk.org  Fri Oct 13 06:53:35 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Oct 2023 06:53:35 GMT
Subject: Integrated: JDK-8317959: Check return values of malloc in native
 java.base coding
In-Reply-To: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
References: <vjeXeUpi_k--LAFMEzy9lCak4gHPuSJGI5cnrQ9u_xU=.a424c98f-3f16-4f1e-ac6d-88efd2dcfe99@github.com>
Message-ID: <wjPXcgAI4h_ckkS0EIiNyZZLeTXefGfkJIYUxfdPw1c=.75af3ed3-bc09-4c20-9f5c-2ce846f790df@github.com>

On Thu, 12 Oct 2023 08:00:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.

This pull request has now been integrated.

Changeset: ff0b397e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff0b397e135665fbc763bc4042b95c17f6c5367a
Stats:     29 lines in 4 files changed: 27 ins; 0 del; 2 mod

8317959: Check return values of malloc in native java.base coding

Reviewed-by: alanb, bpb

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

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

From sgehwolf at openjdk.org  Fri Oct 13 09:06:20 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 13 Oct 2023 09:06:20 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v14]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <vlS0WitGiZps7ziMxUncHLZ88N_wOMF2lUU_FzyGIto=.6b97674e-4645-41d2-8597-696f2557da40@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Severin Gehwolf 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 20 additional commits since the last revision:

 - Drop @enablePreview in CreationTime test
 - Merge branch 'master'
 - Move trace message after platform specific blocks
 - Drop word 'Debug:' in CreationTime test code
 - Keep wrapper function signature compatible to statx
 - Refactor test so as to use Linker from JEP 454.
   
   @enablePreview still needed as of yet. This can go once
   JDK-8312522 integrates.
 - Add missing returns when statx is available
 - Use custom but compatible statx struct always
 - Link libCreationTimeHelper with -ldl
 - Merge branch 'master' into JDK-8316304-statx-create-time-new
 - ... and 10 more: https://git.openjdk.org/jdk/compare/80229be5...9fcdd965

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/cbb24e38..9fcdd965

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=12-13

  Stats: 20110 lines in 677 files changed: 10264 ins; 4891 del; 4955 mod
  Patch: https://git.openjdk.org/jdk/pull/15792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792

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

From sgehwolf at openjdk.org  Fri Oct 13 09:06:22 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 13 Oct 2023 09:06:22 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v13]
In-Reply-To: <exrhsvh9UZLVfLRmmTxONmTPXBRpEAqq126jZgzE8vA=.687b64b2-a602-41fe-a9db-8a557b5e6dd3@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <exrhsvh9UZLVfLRmmTxONmTPXBRpEAqq126jZgzE8vA=.687b64b2-a602-41fe-a9db-8a557b5e6dd3@github.com>
Message-ID: <1xQOfkZnHpGNwWmy1JjmKlnLle_kSB0fT6vnZVBlSQA=.989f8208-69d4-4d9a-94c7-bdf7a06e69be@github.com>

On Tue, 10 Oct 2023 08:44:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move trace message after platform specific blocks

https://github.com/openjdk/jdk/pull/15103 has been integrated now. I've merged master and removed `@enablePreview` from the test. No other changes have been done. I'm going to do a final round of testing and will probably integrate next week Monday.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1761167856

From sgehwolf at openjdk.org  Fri Oct 13 14:50:44 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 13 Oct 2023 14:50:44 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v15]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

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

  Fix Linux Alpine build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/9fcdd965..71ab818a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=13-14

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

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

From sgehwolf at openjdk.org  Fri Oct 13 14:51:10 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 13 Oct 2023 14:51:10 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v15]
In-Reply-To: <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
Message-ID: <4F4lcuo_OVfTSCYouosLi1K6YUvGs7DWxda3MYuefDs=.54fede75-f357-4efe-b4f1-ffbca93a5062@github.com>

On Fri, 13 Oct 2023 14:50:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Linux Alpine build

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 87:

> 85: typedef unsigned short     __uint16_t;
> 86: typedef unsigned long int  __uint64_t;
> 87: #endif

Not sure what changed on the lastest merge from master, but I was getting compile failures on Apine without this. It's a no-op for glibc. @AlanBateman @bplb Still ok?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1358366992

From alanb at openjdk.org  Fri Oct 13 14:55:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Oct 2023 14:55:07 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v15]
In-Reply-To: <4F4lcuo_OVfTSCYouosLi1K6YUvGs7DWxda3MYuefDs=.54fede75-f357-4efe-b4f1-ffbca93a5062@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
 <4F4lcuo_OVfTSCYouosLi1K6YUvGs7DWxda3MYuefDs=.54fede75-f357-4efe-b4f1-ffbca93a5062@github.com>
Message-ID: <IKu5_XuyQ35ztxKegKKjXeee_-Fkp32ioop-eBg5vLs=.97262c65-63d9-405a-a78e-835527b374b2@github.com>

On Fri, 13 Oct 2023 14:48:08 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Not sure what changed on the lastest merge from master, but I was getting compile failures on Apine without this. It's a no-op for glibc. @AlanBateman @bplb Still ok?

Yes, I don't have any other comments and I see you've dropped the enablePreview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1358372178

From mcimadamore at openjdk.org  Fri Oct 13 15:50:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 15:50:12 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl
Message-ID: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>

This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
Doing so addresses a possible deadlock condition when using multiple threads.

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

Commit messages:
 - Add test
 - Add copyright
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/16187/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317514
  Stats: 484 lines in 12 files changed: 313 ins; 147 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16187/head:pull/16187

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

From bpb at openjdk.org  Fri Oct 13 16:20:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Oct 2023 16:20:53 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v15]
In-Reply-To: <IKu5_XuyQ35ztxKegKKjXeee_-Fkp32ioop-eBg5vLs=.97262c65-63d9-405a-a78e-835527b374b2@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
 <4F4lcuo_OVfTSCYouosLi1K6YUvGs7DWxda3MYuefDs=.54fede75-f357-4efe-b4f1-ffbca93a5062@github.com>
 <IKu5_XuyQ35ztxKegKKjXeee_-Fkp32ioop-eBg5vLs=.97262c65-63d9-405a-a78e-835527b374b2@github.com>
Message-ID: <KHERLUjWf04x7W2WFG0Zs6vomVRV502G5Qf6bkRV8ug=.c1b7a076-acaa-4fc2-a9e8-2e86ebce9f67@github.com>

On Fri, 13 Oct 2023 14:52:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 87:
>> 
>>> 85: typedef unsigned short     __uint16_t;
>>> 86: typedef unsigned long int  __uint64_t;
>>> 87: #endif
>> 
>> Not sure what changed on the lastest merge from master, but I was getting compile failures on Apine without this. It's a no-op for glibc. @AlanBateman @bplb Still ok?
>
>> Not sure what changed on the lastest merge from master, but I was getting compile failures on Apine without this. It's a no-op for glibc. @AlanBateman @bplb Still ok?
> 
> Yes, I don't have any other comments and I see you've dropped the enablePreview.

Likewise. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1358477573

From bpb at openjdk.org  Fri Oct 13 16:34:34 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Oct 2023 16:34:34 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v15]
In-Reply-To: <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
Message-ID: <NQW_cegwtwBu1OBNNvEL-_UBWxZZWMSKNDthgFxjVDo=.6804363d-00d2-419d-b77b-eeb31f5ad8b3@github.com>

On Fri, 13 Oct 2023 14:50:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Linux Alpine build

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1676858578

From jvernee at openjdk.org  Fri Oct 13 17:10:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 17:10:14 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl
In-Reply-To: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>
References: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>
Message-ID: <xqEjiNxxYjdAYhdm2Mb7JFiqymvCRdZZukrK_ivAcg8=.6c9b72db-6420-48b2-8d34-3a49f8040b91@github.com>

On Fri, 13 Oct 2023 15:37:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
> Doing so addresses a possible deadlock condition when using multiple threads.

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1289:

> 1287:      * A zero-length native segment modelling the {@code NULL} address.
> 1288:      */
> 1289:     MemorySegment NULL = MemorySegment.ofAddress(0L);

The old no-arg constructor can now be removed from NativeMemroySegmentImpl as well I believe.

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

PR Review: https://git.openjdk.org/jdk/pull/16187#pullrequestreview-1676911705
PR Review Comment: https://git.openjdk.org/jdk/pull/16187#discussion_r1358523909

From mcimadamore at openjdk.org  Fri Oct 13 17:31:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 17:31:15 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl [v2]
In-Reply-To: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>
References: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>
Message-ID: <HjESQdC2aaqj0CJEBlP3F6fQE1_HGIkjbYVeANW0JOQ=.fb1c8df9-55b4-42f0-942c-b261ed6ff699@github.com>

> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
> Doing so addresses a possible deadlock condition when using multiple threads.

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16187/files
  - new: https://git.openjdk.org/jdk/pull/16187/files/2aad11cf..b9ad352b

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

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

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

From jvernee at openjdk.org  Fri Oct 13 17:31:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 17:31:16 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl [v2]
In-Reply-To: <HjESQdC2aaqj0CJEBlP3F6fQE1_HGIkjbYVeANW0JOQ=.fb1c8df9-55b4-42f0-942c-b261ed6ff699@github.com>
References: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>
 <HjESQdC2aaqj0CJEBlP3F6fQE1_HGIkjbYVeANW0JOQ=.fb1c8df9-55b4-42f0-942c-b261ed6ff699@github.com>
Message-ID: <77pUHxjLJRpzN6PqTTlTW7t6wXKtSSFKGpXVVweEeao=.ac315f09-33be-4f43-9169-2599f6c58b41@github.com>

On Fri, 13 Oct 2023 17:25:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
>> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
>> Doing so addresses a possible deadlock condition when using multiple threads.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16187#pullrequestreview-1676985669

From pminborg at openjdk.org  Fri Oct 13 17:48:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Oct 2023 17:48:09 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl [v2]
In-Reply-To: <HjESQdC2aaqj0CJEBlP3F6fQE1_HGIkjbYVeANW0JOQ=.fb1c8df9-55b4-42f0-942c-b261ed6ff699@github.com>
References: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>
 <HjESQdC2aaqj0CJEBlP3F6fQE1_HGIkjbYVeANW0JOQ=.fb1c8df9-55b4-42f0-942c-b261ed6ff699@github.com>
Message-ID: <ff3Of7ZFa7HUdDVZd2CZU1vfayGrQHa8Y92Itq5Dz_w=.46b6296b-7c5a-479e-8340-524a1d117e17@github.com>

On Fri, 13 Oct 2023 17:31:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
>> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
>> Doing so addresses a possible deadlock condition when using multiple threads.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 49:

> 47:  */
> 48: public class SegmentFactories {
> 49: 

We could make this a proper utility class by declaring the class final and having a private constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16187#discussion_r1358610000

From mcimadamore at openjdk.org  Fri Oct 13 21:30:13 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 21:30:13 GMT
Subject: Integrated: 8317514: Ensure MemorySegment is initialized before
 touching NativeMemorySegmentImpl
In-Reply-To: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>
References: <pJwCntsHLXOcS-V40_AzoSRBxYVWljcUR3Dkkp0B6V4=.cd040188-742a-4a86-a6e5-76fb5274a5d0@github.com>
Message-ID: <zqKR47KpP3batvPchKYdQQ1e_ozA2WiixAtEn5nO6hc=.73a0c081-4f01-4f7e-9fef-122d02786a96@github.com>

On Fri, 13 Oct 2023 15:37:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
> Doing so addresses a possible deadlock condition when using multiple threads.

This pull request has now been integrated.

Changeset: 7cb2e6d6
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7cb2e6d65b517b638a584149560a2ff9cc56c3b6
Stats:     496 lines in 12 files changed: 313 ins; 158 del; 25 mod

8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl

Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Reviewed-by: jvernee

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

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

From mli at openjdk.org  Sat Oct 14 18:20:54 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 14 Oct 2023 18:20:54 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v15]
In-Reply-To: <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
Message-ID: <FFK-_LG_PWAChJdsQirmf0B08A4tB6f1rTFoonQu1R4=.f545987f-19fb-4dc2-b0d9-fba10a477906@github.com>

On Fri, 13 Oct 2023 14:50:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Linux Alpine build

LGTM.

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1678309912

From duke at openjdk.org  Mon Oct 16 02:15:32 2023
From: duke at openjdk.org (xpbob)
Date: Mon, 16 Oct 2023 02:15:32 GMT
Subject: Withdrawn: 8318058: Notify the jvm when the direct memory is oom
In-Reply-To: <c3tlbNBprc7M5j89f1tB498ICCMX64PNyvilpzkkFjA=.2b33fd0f-fbe5-4e26-81ed-d6638b765edd@github.com>
References: <c3tlbNBprc7M5j89f1tB498ICCMX64PNyvilpzkkFjA=.2b33fd0f-fbe5-4e26-81ed-d6638b765edd@github.com>
Message-ID: <0FMEIyZwzX0DoJNG8hnJpN0ey6Ox_SjPLK0gJ1COJ3A=.21bbcd0a-ded3-4a66-b13e-c190f094b3ef@github.com>

On Fri, 13 Oct 2023 03:23:04 GMT, xpbob <duke at openjdk.org> wrote:

> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Oct 16 03:22:04 2023
From: duke at openjdk.org (xpbob)
Date: Mon, 16 Oct 2023 03:22:04 GMT
Subject: RFR: 8318058: Notify the jvm when the direct memory is oom
In-Reply-To: <yVZKJQ5xkAqHGKfnbHgLLtbhFN5OhYPWYSGwpsg_cfQ=.b0ededba-0b03-4f5f-80fc-a0f2e8740b4e@github.com>
References: <c3tlbNBprc7M5j89f1tB498ICCMX64PNyvilpzkkFjA=.2b33fd0f-fbe5-4e26-81ed-d6638b765edd@github.com>
 <yVZKJQ5xkAqHGKfnbHgLLtbhFN5OhYPWYSGwpsg_cfQ=.b0ededba-0b03-4f5f-80fc-a0f2e8740b4e@github.com>
Message-ID: <c81wc2vHxKxL2PuHFzfhZiOxc8AwoGk9rpW-tXVJ6So=.1532a770-d4e7-4b6b-bfc2-c1faedd18acb@github.com>

On Fri, 13 Oct 2023 05:26:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
>> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
>> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod
>
> Undoubtedly useful, but there have been many discussions in the past about what does and does not constitute an OOM error, and IIRC, the stance of Oracle devs was "only if it is in java heap". Hence the missing OOM error when we cannot create threads, for instance.

@tstuefe @AlanBateman 
Thanks for for sharing this information,
We look forward to other solutions to this problem in the future

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

PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1763663559

From sgehwolf at openjdk.org  Mon Oct 16 07:27:02 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 16 Oct 2023 07:27:02 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v15]
In-Reply-To: <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wVP8lAKSejWfEldbgJ3G9eIPBgaaImcON-vhOm6-1SY=.4d23afc0-71c0-459c-b0c7-c5d8d7dce232@github.com>
Message-ID: <haL71WMsJ-UTZc5XhrPR56PsO-G575PcBrGg9gYNcBk=.320ee9b3-a7f6-42f5-8c36-2e94700ecbaf@github.com>

On Fri, 13 Oct 2023 14:50:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Linux Alpine build

GHA's x86 (32bit) Linux tier1 test failure seems unrelated.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1763874402

From sgehwolf at openjdk.org  Mon Oct 16 07:44:17 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 16 Oct 2023 07:44:17 GMT
Subject: Integrated: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <olFZx9wrwN7WirQ5Gd1WSr9WMUYIuwtCVX34Gu39TP4=.6a8b35fd-d59c-4161-bd26-5bc5a8815760@github.com>

On Mon, 18 Sep 2023 17:05:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 0275efac
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0275efac882d263f85a723828a95d621f8dadbfb
Stats:     245 lines in 3 files changed: 229 ins; 0 del; 16 mod

8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux

Reviewed-by: stuefe, alanb, bpb, mli

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

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

From jpai at openjdk.org  Mon Oct 16 10:31:03 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Oct 2023 10:31:03 GMT
Subject: RFR: 8312527: (ch) Re-examine use of
 sun.nio.ch.Invoker.myGroupAndInvokeCount
In-Reply-To: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>
References: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>
Message-ID: <w474jn5z6LMbjUMb5QuYu5ubUo86tS4CdN4O8KTntH4=.c2f591f5-32c0-49a0-819d-74e0f0040ff5@github.com>

On Thu, 12 Oct 2023 19:13:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`.

The change looks fine to me

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16170#pullrequestreview-1679600411

From bpb at openjdk.org  Mon Oct 16 14:52:25 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Oct 2023 14:52:25 GMT
Subject: Integrated: 8317687: (fs) FileStore.supportsFileAttributeView("posix")
 incorrectly returns 'true' for FAT32 volume on macOS
In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com>
Message-ID: <ADMraoralxUUbV-dq6m5xV8RQlb4kYBHL2QDVwOWudQ=.2dd3d2e4-0c53-4057-ac52-418de6ba39e4@github.com>

On Fri, 6 Oct 2023 21:39:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32.

This pull request has now been integrated.

Changeset: 1a7fd5d4
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a7fd5d41901249f8e1e6f0aa1f2a3c9f265659d
Stats:     36 lines in 3 files changed: 30 ins; 1 del; 5 mod

8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Mon Oct 16 14:56:00 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Oct 2023 14:56:00 GMT
Subject: Integrated: 8312527: (ch) Re-examine use of
 sun.nio.ch.Invoker.myGroupAndInvokeCount
In-Reply-To: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>
References: <Ih-h8pkhveFutow2rIWq8AMLykUbWl_jAxMRDfLDLiE=.14d35fe8-8c43-4c5b-9b04-5579f88eec17@github.com>
Message-ID: <Ob8N1iNLgZeligxt3d65gF1IRj-zE3D_KbborVXx1dw=.f4a3b460-64f0-4b3e-b005-11d9c632fef3@github.com>

On Thu, 12 Oct 2023 19:13:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`.

This pull request has now been integrated.

Changeset: 0d091681
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d091681c2e440d05dc913131fbc2bdf4f15a31b
Stats:     7 lines in 1 file changed: 0 ins; 4 del; 3 mod

8312527: (ch) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount

Reviewed-by: alanb, jpai

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

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

From bpb at openjdk.org  Mon Oct 16 21:25:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Oct 2023 21:25:52 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data
Message-ID: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>

Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

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

Commit messages:
 - 8306308: (ch) Writer created by Channels::newWriter may lose data

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

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

From bpb at openjdk.org  Mon Oct 16 21:25:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Oct 2023 21:25:53 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <DRC5ClIfzfbaSSHrfF9d0PWYXxSGHJtP9uRSG6Zl4ck=.8fb19a3d-2168-4063-ab26-9d082188d3f1@github.com>

On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

I am not entirely certain that this change is exactly what @djelinski intended in his [comment](https://bugs.openjdk.org/browse/JDK-8306308?focusedCommentId=14575246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14575246) on the issue.

No tests are included pending comments on whether this is the right approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1765298062

From duke at openjdk.org  Mon Oct 16 22:33:26 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 22:33:26 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does
 not throw CharacterCodingException
Message-ID: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>

When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

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

Commit messages:
 - Make the NoRepl methods throw IllegalArgument

Changes: https://git.openjdk.org/jdk/pull/16209/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318200
  Stats: 93 lines in 8 files changed: 10 ins; 58 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/16209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209

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

From liach at openjdk.org  Tue Oct 17 03:12:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Oct 2023 03:12:21 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>

On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

src/java.base/share/classes/java/lang/String.java line 932:

> 930: 
> 931:     private static byte[] getBytesNoRepl1(String s, Charset cs) {
> 932:         return getBytesNoRepl1(s, cs);

This method should probably be removed. This current implementation is an infinite recursion.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 319:

> 317:                 }
> 318:             } catch (IllegalArgumentException e) {
> 319:                 return Comparison.NO_MATCH;

Should check if the cause is `CharacterCodingException`

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

Changes requested by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/16209#pullrequestreview-1681283802
PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361455389
PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361455717

From duke at openjdk.org  Tue Oct 17 03:22:56 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 03:22:56 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <uBEU92GDEPocWi5zI0E3mQdzQyfE5YvddA3-zDnPhC0=.28191342-1e25-49a1-8529-03538c311f68@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

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

  fix from @liach 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/aa76c505..d2063b08

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

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

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

From alanb at openjdk.org  Tue Oct 17 06:00:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 06:00:19 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <o5OIcqcpsNFenvE55OPRWJiOdjvkI5pq6P7PwdIwE0s=.12ccd87f-a835-428d-9dfb-14a61cdaee67@github.com>

On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

It's a simple approach but I think you'll create to some some benchmarks to demonstrate that the channel handling in StreamEncoder can be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1765718960

From djelinski at openjdk.org  Tue Oct 17 06:41:24 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 17 Oct 2023 06:41:24 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <McNW-PxBdzeSMBkV_Azj1V3tSP_FF6UrL7Mm1kXv1_M=.e4c19ac2-e9c5-4b5f-ba20-45c129c85ac1@github.com>

On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

Yes, that's what I had in mind.
Note that this was the only place where `StreamEncoder.forEncoder` was used, which in turn was the only place where `StreamEncoder(WritableByteChannel ch, CharsetEncoder enc, int mbc)` was used, which in turn was the only place where `StreamEncoder#ch` was set, so this PR has potential to make the code much simpler.

src/java.base/share/classes/java/nio/channels/Channels.java line 544:

> 542:     {
> 543:         Objects.requireNonNull(ch, "ch");
> 544:         return StreamEncoder.forEncoder(ch, enc.reset(), minBufferCap);

You could avoid one level of indirection by using `StreamEncoder.forOutputStreamWriter` instead of `new OutputStreamWriter` here. `OutputStreamWriter` is a pass-through wrapper for `StreamEncoder.forOutputStreamWriter` (except for [JDK-6856817](https://bugs.openjdk.org/browse/JDK-6856817) / dc93a924ee4d3b53f0271af577148f8a53eedb57, but that's another story)

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

PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1681459462
PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1361569579

From redestad at openjdk.org  Tue Oct 17 09:34:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Oct 2023 09:34:22 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>
Message-ID: <FRlXtni8mqAfPaTetCo2745x_b4yZnBQa5YTBnZVggk=.30c0e192-f563-4043-a6ae-52f759ca7b3a@github.com>

On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix from @liach 's review
>
> The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

I agree with @liach that `Files.readString / writeString` should continue to throw `CCE`, not `IAE`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766035016

From alanb at openjdk.org  Tue Oct 17 10:36:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 10:36:14 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <U4zDNz9-1oK3DNUNdywS1KNgS6eomCriQanktTVrBxE=.abd444f5-671b-4d9e-95ec-a572a05fc53d@github.com>
Message-ID: <Z3iDeeamWd9xO9ubJKKfW3IBNbpCywZPjdJv5-6XQ-Q=.66cdb1c1-05a1-42aa-8d37-091afed5b69b@github.com>

On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang <liach at openjdk.org> wrote:

> The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

Right, these APIs are specified to throw an IOException "If an I/O error occurs reading from the file or a malformed or unmappable byte sequence is read". Changing this to throw an unexpected IAE would be a breaking change. So good to spot this. Need to make sure that tier2 tests are run with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766104613

From egahlin at openjdk.org  Tue Oct 17 10:39:34 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 17 Oct 2023 10:39:34 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events [v2]
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com>

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Update microbenchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15908/files
  - new: https://git.openjdk.org/jdk/pull/15908/files/3b398bc4..185f6bfa

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

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

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

From duke at openjdk.org  Tue Oct 17 10:42:59 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 10:42:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v3]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

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

  Files.readString/writeString throws CCE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/d2063b08..a93be313

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

  Stats: 22 lines in 3 files changed: 16 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209

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

From redestad at openjdk.org  Tue Oct 17 10:45:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Oct 2023 10:45:22 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v3]
In-Reply-To: <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>
Message-ID: <rdO145zAvUiv4srzlq69oOFrjEMNpR61fDNbam_EOX8=.cb536a25-2f91-4c09-bd84-99e307bada23@github.com>

On Tue, 17 Oct 2023 10:42:59 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files.readString/writeString throws CCE

test/jdk/java/lang/String/NoReplTest.java line 62:

> 60:                             .withUpperCase()
> 61:                             .formatHex(read.getBytes(UTF_16)));
> 62:         } catch (CharacterCodingException cce) {

Shouldn't these test changes be completely reverted now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361904067

From duke at openjdk.org  Tue Oct 17 11:11:52 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 11:11:52 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

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

  revert NoReplTest, from @cl4es 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/a93be313..cc3bc9ed

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

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

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

From alanb at openjdk.org  Tue Oct 17 11:15:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 11:15:51 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
Message-ID: <E08AepxGA8OzEZeTREiCbMhzSnnvlqh77AJcOfystuQ=.fc0d6647-0aca-416d-8bb4-c96229e15123@github.com>

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

src/java.base/share/classes/java/nio/file/Files.java line 3361:

> 3359:                 throw cause;
> 3360:             }
> 3361:             throw e;

This is wrong, if IAE is thrown for any other reason than CharacterCodingException then it means the JDK is broken.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361937982

From alanb at openjdk.org  Tue Oct 17 11:19:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 11:19:00 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
Message-ID: <sSWobByGIMZOlW7k9XqVOLQrsHEme6oGqwVMIJVr-4I=.0d67b44e-a9cd-428e-ae79-92899233f319@github.com>

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

I've set this PR to require two Reviewers as there is obvious breakage here and no evidence that the tier2 tests have been run.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766203522

From lkorinth at openjdk.org  Tue Oct 17 12:29:46 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 17 Oct 2023 12:29:46 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v4]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:

 - Revert "8315097: Rename createJavaProcessBuilder"
   
   This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
 - Revert "copyright"
   
   This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
 - Revert "fix static import"
   
   This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/27da7150..44af07b9

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

  Stats: 1102 lines in 462 files changed: 11 ins; 22 del; 1069 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From mgronlun at openjdk.org  Tue Oct 17 13:00:24 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 17 Oct 2023 13:00:24 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events [v2]
In-Reply-To: <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
 <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com>
Message-ID: <StL9XOAf3EgImjycW2fxpbiT8athNi2akKtgtKJR7NM=.369ca9d2-4fa6-468c-8001-36c36db1f55a@github.com>

On Tue, 17 Oct 2023 10:39:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi,
>> 
>> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update microbenchmark

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15908#pullrequestreview-1682264504

From egahlin at openjdk.org  Tue Oct 17 14:03:11 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 17 Oct 2023 14:03:11 GMT
Subject: Integrated: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <xJvbr7iwS00F-ncKQiVeRlXJFjeucSZJsdAwzM00D0Q=.546043a4-19ce-4c5a-b26c-064acf65765b@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 6aa837ee
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6aa837eee62c2243689142915abcd85db85d0eed
Stats:     55 lines in 5 files changed: 26 ins; 6 del; 23 mod

8316927: JFR: Move shouldCommit check earlier for socket events

Reviewed-by: alanb, dfuchs, mgronlun

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

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

From rgiulietti at openjdk.org  Tue Oct 17 14:12:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 14:12:07 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
Message-ID: <z5adw0jB4_r_SJyls6NRbjonqj8M8edF26yr8gWGzzg=.d35bc66d-34b2-4ade-964b-c596479e4406@github.com>

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

@wenshao The proposal changes the exception types for seemingly no reason.
What concrete problem does this enhancement PR address?

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766499191

From duke at openjdk.org  Tue Oct 17 14:22:10 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 14:22:10 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

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

  fix from @AlanBateman 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/cc3bc9ed..f7023991

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

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

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

From duke at openjdk.org  Tue Oct 17 14:36:40 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 14:36:40 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <z5adw0jB4_r_SJyls6NRbjonqj8M8edF26yr8gWGzzg=.d35bc66d-34b2-4ade-964b-c596479e4406@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
 <z5adw0jB4_r_SJyls6NRbjonqj8M8edF26yr8gWGzzg=.d35bc66d-34b2-4ade-964b-c596479e4406@github.com>
Message-ID: <xhjiNfqPxaQx0sUbfnYnKHklpTFlgG2jn_XAhPgjmtg=.f1ce9f92-f8a7-421c-9e9d-939b4907d865@github.com>

On Tue, 17 Oct 2023 14:09:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> @wenshao The proposal changes the exception types for seemingly no reason. What concrete problem does this enhancement PR address?

@lianch 's suggestion in PR #14812 : 
"Make the NoRepl methods throw IllegalArgument (like NoRepl1 do) by default; move the exception handling logic into Files implementation, the only place where it's actually needed. "

We used noRepl in UUID/HexFormat to handle CCE. I felt that the code was not clean enough, so I submitted this PR.

After the discussion above, I found that things are not that simple. Should I continue this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766540065

From liach at openjdk.org  Tue Oct 17 14:43:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Oct 2023 14:43:52 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <xhjiNfqPxaQx0sUbfnYnKHklpTFlgG2jn_XAhPgjmtg=.f1ce9f92-f8a7-421c-9e9d-939b4907d865@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <fs6v-gPf5R5kx-rZhj8JkgHOyk4Zoreca91x281Hid0=.aa49f629-3456-4430-9727-1d77449d0382@github.com>
 <z5adw0jB4_r_SJyls6NRbjonqj8M8edF26yr8gWGzzg=.d35bc66d-34b2-4ade-964b-c596479e4406@github.com>
 <xhjiNfqPxaQx0sUbfnYnKHklpTFlgG2jn_XAhPgjmtg=.f1ce9f92-f8a7-421c-9e9d-939b4907d865@github.com>
Message-ID: <wNmL-X3JCNaAWgz1abkEj1EhZsWbhN2_DP7HtERda6s=.bfbb68e1-be70-478b-b6fe-023b43c7cfbc@github.com>

On Tue, 17 Oct 2023 14:30:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> @wenshao The proposal changes the exception types for seemingly no reason.
> What concrete problem does this enhancement PR address?

@rgiulietti The API was exposed to create a String without duplicating an array in compatible encoding. Initially they are added for Files.readString and writeString, which has a custom exception logic. However, in the coming years, the usages for no-replication has grown, but no other user needs the CCE behavior, which makes code complex. As a result, we are proposing to localize the CCE logoc to Files.readString and writeString so other use sites can call the APIs without try-catch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766561936

From bpb at openjdk.org  Tue Oct 17 15:13:22 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Oct 2023 15:13:22 GMT
Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for
 CharSequence [v6]
In-Reply-To: <XA2IKkx3056HBqJYnnTV-YeP0xa2MLC2z62QkG9pAAY=.7f93eeaf-579b-45d5-adf5-37122ef094e7@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <XA2IKkx3056HBqJYnnTV-YeP0xa2MLC2z62QkG9pAAY=.7f93eeaf-579b-45d5-adf5-37122ef094e7@github.com>
Message-ID: <HhEg75Qnyb8h8iGb0fVB0z3IdZ_fpHAbtLWxRkxUyOc=.3efaa363-162e-4b6f-bd47-b2bce820898e@github.com>

On Mon, 9 Oct 2023 21:19:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4860681: Make test use RandomFactory

CSR created,

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

PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1766621300

From bpb at openjdk.org  Tue Oct 17 15:16:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Oct 2023 15:16:46 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <WN2rYj2EHLEcPVEXJ2K-lAG9DCiqc30GKx-Rvlz-_4A=.c5bb421a-177a-4bca-8234-e61ae358fb77@github.com>

On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

This was just a first stab to elicit comments and verify the approach. Note that this would make `minBufferCap` irrelevant. I wonder whether some sort of `@xyzNote` would be appropriate to make that obvious.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1766627675

From bpb at openjdk.org  Tue Oct 17 17:29:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Oct 2023 17:29:06 GMT
Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for
 CharSequence [v6]
In-Reply-To: <XA2IKkx3056HBqJYnnTV-YeP0xa2MLC2z62QkG9pAAY=.7f93eeaf-579b-45d5-adf5-37122ef094e7@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <XA2IKkx3056HBqJYnnTV-YeP0xa2MLC2z62QkG9pAAY=.7f93eeaf-579b-45d5-adf5-37122ef094e7@github.com>
Message-ID: <NLNaXWvR9eEkJMzhQVoHpZN1YudSV7lwi3y8P4SeUcc=.881e383d-d197-41bb-8e7d-0b759170942f@github.com>

On Mon, 9 Oct 2023 21:19:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4860681: Make test use RandomFactory

Please take note of the **API Note** in the new method.

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

PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1766858873

From rriggs at openjdk.org  Tue Oct 17 18:09:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Oct 2023 18:09:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
Message-ID: <2s6POSrQenTCvzxYraKH7J4oGJ4UqTiDl5ppDTYZ1fM=.fdb440b4-d33e-46e2-98b5-bd629b2b8c3e@github.com>

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

Hacking around the exception types isn't a good fix.
If the exception is thrown, it is because of a charset conversion error.
IllegalArgumentException is for cases where the arguments are incorrect.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16209#pullrequestreview-1683043411

From bpb at openjdk.org  Tue Oct 17 20:00:38 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Oct 2023 20:00:38 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
Message-ID: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>

Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

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

Commit messages:
 - 8298318: (fs) APIs for handling filename extensions

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

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

From bpb at openjdk.org  Tue Oct 17 20:00:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Oct 2023 20:00:39 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <jcJcgfsKF-vPy6cNqLhdoMNiovdhiaUsqkrrB1eiv1Q=.a3a9522c-3873-4fac-b34f-6f7f698a4a43@github.com>

On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

This request follows from previous work outlined in this [nio-dev thread](https://mail.openjdk.org/pipermail/nio-dev/2023-October/015084.html).

For a given `Path` `p`, the following invariant obtains:

assert p.equals(p.removeExtension().addExtension(p.getExtension()));

Replacing an extension may be accomplished by composing the removal and addition methods as:

jshell> Path losslessImage = Path.of("photo.png");
losslessImage ==> photo.png

jshell> Path lossyImage = losslessImage.removeExtension().addExtension("jpg");
lossyImage ==> photo.jpg

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1767071295

From bpb at openjdk.org  Tue Oct 17 20:07:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Oct 2023 20:07:45 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <VNdykzgHRMaKcNtQns4geSkNWZu0vjFJBDPRnJrOOjc=.27e3c8c1-9d9d-4dd1-a0e2-4b009670f77a@github.com>

On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

The UNIX-specific implementation is intentionally omitted for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1767087988

From bpb at openjdk.org  Tue Oct 17 21:03:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Oct 2023 21:03:27 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <0UnMZSi5E4-QLA1kk_IWXkNonWH3DEBQjCWykKIS2JQ=.d7fb2580-7339-4d48-92b6-1917049f49fe@github.com>

On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

A CSR will be created once there is reasonable consensus on the verbiage in this conversation.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1767164134

From bpb at openjdk.org  Wed Oct 18 01:01:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 01:01:27 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v2]
In-Reply-To: <McNW-PxBdzeSMBkV_Azj1V3tSP_FF6UrL7Mm1kXv1_M=.e4c19ac2-e9c5-4b5f-ba20-45c129c85ac1@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <McNW-PxBdzeSMBkV_Azj1V3tSP_FF6UrL7Mm1kXv1_M=.e4c19ac2-e9c5-4b5f-ba20-45c129c85ac1@github.com>
Message-ID: <lTKd6Q8d7EH-voNs5n9hSOSlgtVespNikaXnV2CsbYk=.8507c3c3-fed5-4ebd-8ff6-85f30eff2195@github.com>

On Tue, 17 Oct 2023 06:38:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> [...] so this PR has potential to make the code much simpler.

So simplified in 1d8a667c0160fe9d698773e6bbf8abc2b8ee2596.

> src/java.base/share/classes/java/nio/channels/Channels.java line 544:
> 
>> 542:     {
>> 543:         Objects.requireNonNull(ch, "ch");
>> 544:         return StreamEncoder.forEncoder(ch, enc.reset(), minBufferCap);
> 
> You could avoid one level of indirection by using `StreamEncoder.forOutputStreamWriter` instead of `new OutputStreamWriter` here. `OutputStreamWriter` is a pass-through wrapper for `StreamEncoder.forOutputStreamWriter` (except for [JDK-6856817](https://bugs.openjdk.org/browse/JDK-6856817) / dc93a924ee4d3b53f0271af577148f8a53eedb57, but that's another story)

So changed in c225b9fae846a673d8c372509aa90cd2ead8a3fd. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1767424639
PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1362967985

From bpb at openjdk.org  Wed Oct 18 01:01:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 01:01:27 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data
In-Reply-To: <o5OIcqcpsNFenvE55OPRWJiOdjvkI5pq6P7PwdIwE0s=.12ccd87f-a835-428d-9dfb-14a61cdaee67@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <o5OIcqcpsNFenvE55OPRWJiOdjvkI5pq6P7PwdIwE0s=.12ccd87f-a835-428d-9dfb-14a61cdaee67@github.com>
Message-ID: <LRH8DtWZM0FGYEezj6-_C0KQCGfgL7bZj-fquT0mbiA=.31abbe6e-534d-4e03-92cf-a1d641aa1995@github.com>

On Tue, 17 Oct 2023 05:57:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] you'll need to create to some benchmarks [...]

Problems running benchmarks today, likely due to version considerations. Will continue that and if it pans out add tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1767426087

From bpb at openjdk.org  Wed Oct 18 01:01:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 01:01:27 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v2]
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <VTjscCpj9iNssuJ3YTGH1igB_J_9y2m2rJc_h1S0j1U=.18376884-279f-4cec-b786-f47d933d3e1e@github.com>

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 8306308: Remove WritableByteChannel support from StreamEncoder
 - 8306308: new OutputStreamWriter -> StreamEncoder.forOutputStreamWriter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16207/files
  - new: https://git.openjdk.org/jdk/pull/16207/files/808dc885..1d8a667c

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

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

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

From alanb at openjdk.org  Wed Oct 18 06:08:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 06:08:42 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <4CJmePEjenBJDIH-gd3XR9TvEhASU0aXz0J7KwgSFAs=.457953ba-c679-4fdd-ae89-0ea68fffc71d@github.com>

On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

I'm too busy right now to spend time on this one but from a quick glance, the proposed addExtension and removeExtension  looks very strange. I think it would be useful to show some examples using them to justify why are needed. Also write out some candidate method names. A Path is immutable so I don't think you want methods with names like addXXX or removeXXX as the resulting usages will look like they mutate the Path.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1767708361

From pminborg at openjdk.org  Wed Oct 18 06:20:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 06:20:54 GMT
Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer
In-Reply-To: <gLVX_igB_vkPMBKxXLr6Q_qQqAwb1B1Sygn8yjAa5VA=.91baaa4b-3ec8-4212-adb0-ffe879ad40f6@github.com>
References: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
 <Y9zBV1kMxDBND57kuTHpf5P-nef-MV1JvnzdjYQpHZ0=.466b7e3d-b27a-4eed-b514-469280d6d4f7@github.com>
 <JBzXwA1QlIlI1-pfhBVoIa4nHq1zkt59LBWVk2J4gUs=.4c83d40b-732a-40fc-a738-12781bb714c9@github.com>
 <gLVX_igB_vkPMBKxXLr6Q_qQqAwb1B1Sygn8yjAa5VA=.91baaa4b-3ec8-4212-adb0-ffe879ad40f6@github.com>
Message-ID: <LG6-32_eMAfMyeuLgENwGt5h3hC9wBU0TjbWfiaEPQU=.4a107f22-1394-43b8-a3a1-4502feca005e@github.com>

On Thu, 12 Oct 2023 13:21:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It works well in Buffer as there is a hierarchy to show. It seems a bit confusing to me to have it also show up in the ByteBuffer docs. Have I missed something or what is the reason for doing this?

The idea is to have graphs for every sealed class that has at least one publicly permitted class. ByteBuffer has one permitted public class in the form of `MappedByteBuffer`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16142#issuecomment-1767733696

From pminborg at openjdk.org  Wed Oct 18 06:20:55 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 06:20:55 GMT
Subject: Integrated: 8317886: Add @sealedGraph to ByteBuffer
In-Reply-To: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
References: <HV8xZsghfgamClpHKJNmT7SeA5HwCrDLtoZfz5Bts4c=.882c50a4-527c-46fe-b22e-44f01c51fd6f@github.com>
Message-ID: <htco8brxAq_5JMUzH4ROmdhEZzqjfOg_dzAyNoQkZCc=.3f0f9d25-ff11-4ba5-915b-aa75cae48754@github.com>

On Wed, 11 Oct 2023 08:59:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to Add @sealedGraph to `ByteBuffer`.

This pull request has now been integrated.

Changeset: 8dd80964
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8dd809642e0e052917451767d2a25dd98b3af3ef
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8317886: Add @sealedGraph to ByteBuffer

Reviewed-by: rriggs, iris

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

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

From duke at openjdk.org  Wed Oct 18 08:29:58 2023
From: duke at openjdk.org (Paul Wagland)
Date: Wed, 18 Oct 2023 08:29:58 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <KjCpNrsn1UzOv5VeBXo1FhIczzjvSmVZ4VMv4ZGoKwg=.4ce5a32f-4ff5-4578-8cae-285d7e1020b0@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
 <KjCpNrsn1UzOv5VeBXo1FhIczzjvSmVZ4VMv4ZGoKwg=.4ce5a32f-4ff5-4578-8cae-285d7e1020b0@github.com>
Message-ID: <xyTt-VJXUhRB41JMmONGO6Plia6aw17PhliKuRV3NaM=.e49c9150-8c55-4eab-b7a7-252883a422e5@github.com>

On Thu, 28 Sep 2023 12:08:02 GMT, Paul Wagland <duke at openjdk.org> wrote:

> @blpb / @AlanBateman : Do you know if this will this also be released to Java 17 and/or Java 21 service packs?

PR #227 is for Java 21, so it looks like at least Java 21. Here's hoping also for Java 17 :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1767908247

From alanb at openjdk.org  Wed Oct 18 08:47:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 08:47:54 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <xyTt-VJXUhRB41JMmONGO6Plia6aw17PhliKuRV3NaM=.e49c9150-8c55-4eab-b7a7-252883a422e5@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
 <KjCpNrsn1UzOv5VeBXo1FhIczzjvSmVZ4VMv4ZGoKwg=.4ce5a32f-4ff5-4578-8cae-285d7e1020b0@github.com>
 <xyTt-VJXUhRB41JMmONGO6Plia6aw17PhliKuRV3NaM=.e49c9150-8c55-4eab-b7a7-252883a422e5@github.com>
Message-ID: <23KwigV0-xEFGxnD2a7jAOcegUCERfLB6j8kson0mMc=.c02a3cea-88ed-4997-b745-81c982a7a183@github.com>

On Wed, 18 Oct 2023 08:05:55 GMT, Paul Wagland <duke at openjdk.org> wrote:

> > @blpb / @AlanBateman : Do you know if this will this also be released to Java 17 and/or Java 21 service packs?
> 
> PR #227 is for Java 21, so it looks like at least Java 21. Here's hoping also for Java 17 :-)

This is not the place to lobby for back ports, I think you are looking for jdk-updates-dev.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1767976677

From mark at lawinegevaar.nl  Wed Oct 18 13:03:27 2023
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Wed, 18 Oct 2023 15:03:27 +0200
Subject: Should AbstractInterruptibleChannel.close() still use a synchronized
 block?
Message-ID: <faa45acd-e248-4482-a32e-d1b8c5cf230e@lawinegevaar.nl>

Prompted by this Stack Overflow question 
[https://stackoverflow.com/q/77315894/466862], I'm wondering if the use 
of a synchronized block in AbstractInterruptibleChannel.close() as-of 
Java 21 is correct, and shouldn't be replaced with a ReentrantLock or 
something else.

As shown in the question, closing of a channel derived from 
AbstractInterruptibleChannel can cause pinning of virtual threads.

Mark
-- 
Mark Rotteveel

From Alan.Bateman at oracle.com  Wed Oct 18 13:32:12 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Oct 2023 14:32:12 +0100
Subject: Should AbstractInterruptibleChannel.close() still use a
 synchronized block?
In-Reply-To: <faa45acd-e248-4482-a32e-d1b8c5cf230e@lawinegevaar.nl>
References: <faa45acd-e248-4482-a32e-d1b8c5cf230e@lawinegevaar.nl>
Message-ID: <72f2ae33-db51-1788-4a56-432695694c87@oracle.com>

On 18/10/2023 14:03, Mark Rotteveel wrote:
> Prompted by this Stack Overflow question 
> [https://stackoverflow.com/q/77315894/466862], I'm wondering if the 
> use of a synchronized block in AbstractInterruptibleChannel.close() 
> as-of Java 21 is correct, and shouldn't be replaced with a 
> ReentrantLock or something else.
>
> As shown in the question, closing of a channel derived from 
> AbstractInterruptibleChannel can cause pinning of virtual threads.

We decided it wasn't worth doing because it's rare to set SO_LINGER. 
Temporary pinning due to contention on the readLock or writeLock when 
closing is okay.

In the mean-time, we are working to remove restriction on synchronized 
blocks. We hope to have something in the loom repo soon.

-Alan

From rriggs at openjdk.org  Wed Oct 18 14:24:00 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 14:24:00 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <c17K1X0TcPWbNHSDlODKtjY54K2f0V_4_n5Q8A1vdnc=.6eeae6ee-84f1-4867-ba1b-2144018e4f05@github.com>

On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

There are a few builder style APIs for immutable objects that have `withXXX` methods that return an instance with the change requested. A `withExtension(String ext)` could handle the common cases for removing, replacing, and adding an extension.

Path p = Path.of("photo.png");
Path base = p.withExtension("") -> "photo" // replaces any extension with the empty extension (and no dot)
p.withExtension("jpg") -> "photo.jpg"      // replaces the extension
base.withExtension("pdf") -> "photo.pdf"   // adds the extension

Removing an extension with `""` may be a bit unusual, perhaps an additional method  would aid discoverablity`basepath()` or `dropExtension`, or `trimExtension`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1768573625

From bpb at openjdk.org  Wed Oct 18 14:36:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 14:36:10 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <23KwigV0-xEFGxnD2a7jAOcegUCERfLB6j8kson0mMc=.c02a3cea-88ed-4997-b745-81c982a7a183@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
 <KjCpNrsn1UzOv5VeBXo1FhIczzjvSmVZ4VMv4ZGoKwg=.4ce5a32f-4ff5-4578-8cae-285d7e1020b0@github.com>
 <xyTt-VJXUhRB41JMmONGO6Plia6aw17PhliKuRV3NaM=.e49c9150-8c55-4eab-b7a7-252883a422e5@github.com>
 <23KwigV0-xEFGxnD2a7jAOcegUCERfLB6j8kson0mMc=.c02a3cea-88ed-4997-b745-81c982a7a183@github.com>
Message-ID: <AJffs7odZ0S9dcVHTOZgKLE49RVLKGC9z2VODGBopNg=.ea151703-06f1-463a-8f9e-bd47b4d009f8@github.com>

On Wed, 18 Oct 2023 08:45:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> PR #227 is for Java 21, so it looks like at least Java 21.

I think you intended https://github.com/openjdk/jdk21u/pull/227.

> Here's hoping also for Java 17 :-)

I already labelled the issue as being desirable for JDK 17 so it should be on the radar. As @AlanBateman indicated, you can lobby for that on [jdk-updates-dev](https://mail.openjdk.org/pipermail/jdk-updates-dev/)

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1768600015

From alanb at openjdk.org  Wed Oct 18 14:46:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 14:46:03 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v2]
In-Reply-To: <VTjscCpj9iNssuJ3YTGH1igB_J_9y2m2rJc_h1S0j1U=.18376884-279f-4cec-b786-f47d933d3e1e@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <VTjscCpj9iNssuJ3YTGH1igB_J_9y2m2rJc_h1S0j1U=.18376884-279f-4cec-b786-f47d933d3e1e@github.com>
Message-ID: <MdKXjCXOK-ZD9KKcAlU32lUIyfzVsSMR1Cgd_KJ6qqE=.9a1180ef-6cfc-4f18-ba5e-eb5196b499b5@github.com>

On Wed, 18 Oct 2023 01:01:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8306308: Remove WritableByteChannel support from StreamEncoder
>  - 8306308: new OutputStreamWriter -> StreamEncoder.forOutputStreamWriter

src/java.base/share/classes/java/nio/channels/Channels.java line 546:

> 544:         Objects.requireNonNull(enc, "enc");
> 545:         return StreamEncoder.forOutputStreamWriter(newOutputStream(ch),
> 546:             new Object(), enc.reset());

I'm not sure about this lock Object, you may have to add a 2-arg forOutputstreamWriter so that the no-arg Writer is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1364012165

From bpb at openjdk.org  Wed Oct 18 15:05:59 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 15:05:59 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <c17K1X0TcPWbNHSDlODKtjY54K2f0V_4_n5Q8A1vdnc=.6eeae6ee-84f1-4867-ba1b-2144018e4f05@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <c17K1X0TcPWbNHSDlODKtjY54K2f0V_4_n5Q8A1vdnc=.6eeae6ee-84f1-4867-ba1b-2144018e4f05@github.com>
Message-ID: <9YzspTburYEbY7hGYqWNmtXGi4-0ikOMPfpbdXS3JrE=.083abb67-1879-494c-8888-64b2f4aad43b@github.com>

On Wed, 18 Oct 2023 14:21:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> There are a few builder style APIs for immutable objects that have `withXXX` methods that return an instance with the change requested.

Some time back I thought of but never proposed a method similar to `withExtension(String)` called `modifyExtension(String parameter)` with behavior

| path    | gus     | ""   | null |
|---------|---------|------|------|
| foo.bar | foo.gus | foo. | foo  |
| foo.    | foo.gus | foo. | foo  |
| foo     | foo.gus | foo. | foo  |

where the 1st column is the path and the 2nd-4th columns are the parameter.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1768659315

From coffeys at openjdk.org  Wed Oct 18 15:36:01 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Oct 2023 15:36:01 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v7]
In-Reply-To: <5i8oE7FeOG7W7B2C5jqyKuGNJ_EHf9POIox606GDhzs=.faa3ffd1-6fa6-4a40-984b-a6557e685c0e@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
 <5i8oE7FeOG7W7B2C5jqyKuGNJ_EHf9POIox606GDhzs=.faa3ffd1-6fa6-4a40-984b-a6557e685c0e@github.com>
Message-ID: <_Vgd0WYiSEwGjpIiBRdafJEZGZSsKoeSGpZ5g0Kn_5o=.8e185a33-025b-49b0-b624-c92ca1ddc0f4@github.com>

On Mon, 18 Sep 2023 13:17:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which improves the Zip64 extra header validation:
>> 
>> - Throw a ZipException If the extra len field is 0 and :
>> -- size, csize, or loc offset are set to 0xFFFFFFFF
>> -- disk starting number is set to 0xFFFF
>> 
>> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
>> 
>> Mach5 tiers 1-3 are clean
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing space

Looks good to me Lance. I note that the extra checks aren't reversed via any sort of system property but given that this fix isn't planned for JDK update releases, that seems fine to me.

early testing by frameworks which create/modify custom zip files will be important.

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15650#pullrequestreview-1685425990

From prappo at openjdk.org  Wed Oct 18 16:24:00 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 18 Oct 2023 16:24:00 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <c17K1X0TcPWbNHSDlODKtjY54K2f0V_4_n5Q8A1vdnc=.6eeae6ee-84f1-4867-ba1b-2144018e4f05@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <c17K1X0TcPWbNHSDlODKtjY54K2f0V_4_n5Q8A1vdnc=.6eeae6ee-84f1-4867-ba1b-2144018e4f05@github.com>
Message-ID: <pvDi2lHO4e88E6TErukEYaFu5Xj92jyiBRW-XWXaq_E=.f6aba1c7-690a-4694-a8c6-3f9a5cc6d44c@github.com>

On Wed, 18 Oct 2023 14:21:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> There are a few builder style APIs for immutable objects that have `withXXX` methods that return an instance with the change requested. A `withExtension(String ext)` could handle the common cases for removing, replacing, and adding an extension.
> 
> ```
> Path p = Path.of("photo.png");
> Path base = p.withExtension("") -> "photo" // replaces any extension with the empty extension (and no dot)
> p.withExtension("jpg") -> "photo.jpg"      // replaces the extension
> base.withExtension("pdf") -> "photo.pdf"   // adds the extension
> ```
> 
> Removing an extension with `""` may be a bit unusual, perhaps an additional method would aid discoverablity`basepath()` or `dropExtension`, or `trimExtension`.

Right. Depending on how frequent an operation of removing extension is, one could also imagine a name such as `withoutExtension()`. We have methods like that in the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1768893893

From rriggs at openjdk.org  Wed Oct 18 16:30:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 16:30:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
Message-ID: <c4KKuM-Q--U1KLWlBr1HfIwtuVLXBw8ot_X93ICSkRU=.295fc5da-ab91-462f-a4de-9fa737653283@github.com>

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array.  The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed.  


     /**
       * Return a String constructed using the byte array containing latin1 (ISO-8859-1) characters.
       * The byte array must not be modified or otherwise referenced or used after the String is created.
       * If COMPACT_STRINGS is true the coder will be LATIN1 and the byte array is the string value;
       * otherwise the contents are inflated to create a UTF16 string.
       */ 
    public String newStringLatin1NoRepl(byte[] src) {
         if (COMPACT_STRINGS)
             return new String(src, LATIN1);
         return new String(StringLatin1.inflate(src, 0, src.length), UTF16);
    }

Creating strings from other encodings that may or have encoding errors should continue to use the current function and handle CCE as required.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768911569

From alanb at openjdk.org  Wed Oct 18 16:43:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 16:43:19 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <c4KKuM-Q--U1KLWlBr1HfIwtuVLXBw8ot_X93ICSkRU=.295fc5da-ab91-462f-a4de-9fa737653283@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
 <c4KKuM-Q--U1KLWlBr1HfIwtuVLXBw8ot_X93ICSkRU=.295fc5da-ab91-462f-a4de-9fa737653283@github.com>
Message-ID: <QBl1DscpCZvgH3CykHU0pGNGYqWxH9fO11mjjXrdYi0=.0f838a37-55e5-4bd0-89fd-954ad5f56245@github.com>

On Wed, 18 Oct 2023 16:27:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array. The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed.

We have to be very careful with proposals like this as it means code outside of java.lang having access to the underlying bytes. I think other alternatives needs to be explored to avoid this and related concerns.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768937914

From bpb at openjdk.org  Wed Oct 18 16:44:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 16:44:12 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <Bqn1chg4AUe7zlellficx5CIzfBlzXFk6CMoTCNXHAU=.f812f719-d8f6-4dd0-b9a1-bd64e844c46c@github.com>

On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

Part of the point of these methods is to cover the various use cases without ever having to deal directly with a period `"."`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1768940324

From rriggs at openjdk.org  Wed Oct 18 17:39:13 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 17:39:13 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <QBl1DscpCZvgH3CykHU0pGNGYqWxH9fO11mjjXrdYi0=.0f838a37-55e5-4bd0-89fd-954ad5f56245@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
 <c4KKuM-Q--U1KLWlBr1HfIwtuVLXBw8ot_X93ICSkRU=.295fc5da-ab91-462f-a4de-9fa737653283@github.com>
 <QBl1DscpCZvgH3CykHU0pGNGYqWxH9fO11mjjXrdYi0=.0f838a37-55e5-4bd0-89fd-954ad5f56245@github.com>
Message-ID: <EeSotk1tQYJ-ulNRj9za1tACprxAICs1nm0z9tWWqy0=.7785f4da-1b9e-4fe2-8357-f34e99bb5648@github.com>

On Wed, 18 Oct 2023 16:39:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We have to be very careful with proposals like this as it means code outside of java.lang having access to the underlying bytes. I think other alternatives needs to be explored to avoid this and related concerns.

Yes, adding another method in the "NoRepl" family needs to be done with care and be narrowly focused.
JLA already exposes several methods that allow the contents of strings to be read from the underlying value or created from caller provided buffers. All to avoid extra allocations and copying.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1769026087

From tprinzing at openjdk.org  Wed Oct 18 18:07:53 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 18 Oct 2023 18:07:53 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket
 adaptor ops
Message-ID: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>

Added jar event support to socket adapters.

Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java

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

Commit messages:
 - add missing return
 - socket adapter changes to build with merged master
 - Merge branch 'master' into JDK-8310978
 - fix copyright date
 - 8310978: JFR events SocektReadEvent and SocketWriteEvent for Socket adaptor ops

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

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

From alanb at openjdk.org  Wed Oct 18 18:16:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 18:16:39 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops
In-Reply-To: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
Message-ID: <IM7URt5DX3Me_XDPAXp6hbeO0ao8vIysYwmQRvUBUS8=.1f5ca7dc-8939-4284-8e3b-4366f5c16227@github.com>

On Wed, 18 Oct 2023 18:00:40 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Added jar event support to socket adapters.
> 
> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java

I don't think we should be changing SocketChannelImpl here. Can you look at sun.nio.SocketInputStream and sun.nio.SocketOutputStream - these are the input/output streams for the socket adapter.

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

PR Comment: https://git.openjdk.org/jdk/pull/16251#issuecomment-1769082038

From duke at openjdk.org  Wed Oct 18 18:17:24 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 18 Oct 2023 18:17:24 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <BZPGvTIT17tJDWjveC3d4ltgh7to3-ISOSt4kuOm_TA=.054bb83a-e0bd-4f36-8ed8-4eab9db9df3f@github.com>
Message-ID: <ysDhEySjAnB44ap6qOosv_0-UH-zxpEly4lgJjW-bPY=.c938682a-950c-42e0-94be-b4cb61106400@github.com>

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

Should we revisit https://github.com/openjdk/jdk/pull/14655?

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1769082700

From tprinzing at openjdk.org  Wed Oct 18 19:05:21 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 18 Oct 2023 19:05:21 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops
In-Reply-To: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
Message-ID: <I0vFmPIg2iiG8yE5N3l2-GpjPHNOnyRpCzo1Bd9aS4s=.160a51f2-afed-445a-8991-2ed876e6e332@github.com>

On Wed, 18 Oct 2023 18:00:40 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Added jar event support to socket adapters.
> 
> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java

okay, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16251#issuecomment-1769147643

From bpb at openjdk.org  Wed Oct 18 19:14:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 19:14:46 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data
In-Reply-To: <o5OIcqcpsNFenvE55OPRWJiOdjvkI5pq6P7PwdIwE0s=.12ccd87f-a835-428d-9dfb-14a61cdaee67@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <o5OIcqcpsNFenvE55OPRWJiOdjvkI5pq6P7PwdIwE0s=.12ccd87f-a835-428d-9dfb-14a61cdaee67@github.com>
Message-ID: <QPo05AYgabTZ5bqG0Lcp11eqVb5S105V2Rx1czx7X88=.b8185963-1a85-4ab5-99a9-7aab8dd37346@github.com>

On Tue, 17 Oct 2023 05:57:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] I think you'll need to create to some benchmarks to demonstrate that the channel handling in StreamEncoder can be removed.

I don't know whether this was the intended sort of benchmark,

    @Param({"4096", "8192", "16384", "32768"})
    public int capacity;

    @Setup
    public void create() throws IOException {
        cbuf = new char[capacity];
        Arrays.fill(cbuf, (char)42);
        fc = FileChannel.open(path, CREATE, TRUNCATE_EXISTING,
                               WRITE, DSYNC);
        writer = Channels.newWriter(fc, "UTF-8");
    }

    @Benchmark
    public char[] testMethod() throws IOException {
        writer.write(cbuf);
        return cbuf;
    }

but I see little difference between the master code results:

Benchmark               (capacity)   Mode  Cnt      Score      Error  Units
MyBenchmark.testMethod        4096  thrpt    5  46120.101 ? 3514.975  ops/s
MyBenchmark.testMethod        8192  thrpt    5  23014.621 ?  703.382  ops/s
MyBenchmark.testMethod       16384  thrpt    5  11355.081 ?  357.569  ops/s
MyBenchmark.testMethod       32768  thrpt    5   5669.087 ?  401.619  ops/s

and those with `WritableByteChannel` support removed from `StreamEncoder`:

Benchmark               (capacity)   Mode  Cnt      Score      Error  Units
MyBenchmark.testMethod        4096  thrpt    5  46431.382 ? 1641.437  ops/s
MyBenchmark.testMethod        8192  thrpt    5  23079.163 ? 1333.578  ops/s
MyBenchmark.testMethod       16384  thrpt    5  11594.550 ?  793.716  ops/s
MyBenchmark.testMethod       32768  thrpt    5   5619.294 ? 1252.580  ops/s

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1769164290

From bpb at openjdk.org  Wed Oct 18 20:40:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 20:40:23 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

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

  8306308: Add some code to dispense with lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16207/files
  - new: https://git.openjdk.org/jdk/pull/16207/files/1d8a667c..366e42c5

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

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

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

From bpb at openjdk.org  Wed Oct 18 20:40:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Oct 2023 20:40:23 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v2]
In-Reply-To: <MdKXjCXOK-ZD9KKcAlU32lUIyfzVsSMR1Cgd_KJ6qqE=.9a1180ef-6cfc-4f18-ba5e-eb5196b499b5@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <VTjscCpj9iNssuJ3YTGH1igB_J_9y2m2rJc_h1S0j1U=.18376884-279f-4cec-b786-f47d933d3e1e@github.com>
 <MdKXjCXOK-ZD9KKcAlU32lUIyfzVsSMR1Cgd_KJ6qqE=.9a1180ef-6cfc-4f18-ba5e-eb5196b499b5@github.com>
Message-ID: <XJyq9G0LnZjn1_g1QAByi2g5KB9CdhHGrOhZeDo3u_A=.b145cad0-7c05-497e-b8df-5275ecd7c92e@github.com>

On Wed, 18 Oct 2023 14:43:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8306308: Remove WritableByteChannel support from StreamEncoder
>>  - 8306308: new OutputStreamWriter -> StreamEncoder.forOutputStreamWriter
>
> src/java.base/share/classes/java/nio/channels/Channels.java line 546:
> 
>> 544:         Objects.requireNonNull(enc, "enc");
>> 545:         return StreamEncoder.forOutputStreamWriter(newOutputStream(ch),
>> 546:             new Object(), enc.reset());
> 
> I'm not sure about this lock Object, you may have to add a 2-arg forOutputstreamWriter so that the no-arg Writer is used.

Done in 366e42c54ef8f04f542f93b5a73a8ad41e60a322.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1364506375

From alanb at openjdk.org  Thu Oct 19 07:40:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Oct 2023 07:40:28 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
Message-ID: <dG8L7ZoGdumlHhpkFtoARIZ-RgTqKIsDZWqAKvo_cE8=.c42179e6-b332-4283-95e9-3ab308002fb2@github.com>

On Wed, 18 Oct 2023 20:40:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Add some code to dispense with lock

I think this looks quite good.

BTW: Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown?

src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 249:

> 247:     private final int maxBufferCapacity;
> 248: 
> 249:     // This must be non-null

I think you can drop that comment now, it only made sense when one is non-null.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1686940025
PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1770237797
PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1365049207

From djelinski at openjdk.org  Thu Oct 19 07:50:26 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 19 Oct 2023 07:50:26 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
Message-ID: <vFDywU0RH6dv9TVevL1UkORxE1Fzy3EeJHQVkM7l_P4=.d87005d4-55df-41f5-af27-4680339ba2e8@github.com>

On Wed, 18 Oct 2023 20:40:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Add some code to dispense with lock

This is benchmarking disk access. Use a blackhole channel instead:

    public void create(Blackhole bh) throws IOException {
        cbuf = new char[capacity];
        Arrays.fill(cbuf, (char)42);
        WritableByteChannel fc = new WritableByteChannel() {
            @Override
            public int write(ByteBuffer src) throws IOException {
                bh.consume(src);
                int remaining = src.remaining();
                src.position(src.limit());
                return remaining;
            }
            @Override
            public boolean isOpen() {
                return true;
            }
            @Override
            public void close() throws IOException {
            }
        };
        writer = Channels.newWriter(fc, "UTF-8");
    }

Before:

Benchmark               (capacity)   Mode  Cnt     Score     Error   Units
WriterBench.testMethod        4096  thrpt   30  7679,273 ? 111,851  ops/ms
WriterBench.testMethod        8192  thrpt   30  4194,707 ?  47,489  ops/ms
WriterBench.testMethod       16384  thrpt   30  2191,705 ?  46,152  ops/ms
WriterBench.testMethod       32768  thrpt   30  1040,875 ?  54,422  ops/ms

After:

Benchmark               (capacity)   Mode  Cnt     Score     Error   Units
WriterBench.testMethod        4096  thrpt   30  7414,422 ? 156,937  ops/ms
WriterBench.testMethod        8192  thrpt   30  4161,465 ? 116,885  ops/ms
WriterBench.testMethod       16384  thrpt   30  2387,347 ?  37,324  ops/ms
WriterBench.testMethod       32768  thrpt   30  1168,550 ?  35,374  ops/ms

(well, still no difference)

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1770252093

From djelinski at openjdk.org  Thu Oct 19 08:05:13 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 19 Oct 2023 08:05:13 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
Message-ID: <Oxz2lKZstA4DsaFOPc-pfgGaP-9-klTmS6xVyucch5k=.36fe4ff7-8fd6-44c4-8e07-a09aeee40e6d@github.com>

On Wed, 18 Oct 2023 20:40:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Add some code to dispense with lock

LGTM

src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 1:

> 1: /*

There's a couple of null checks that can be removed now:
https://github.com/openjdk/jdk/blob/366e42c54ef8f04f542f93b5a73a8ad41e60a322/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java#L393
https://github.com/openjdk/jdk/blob/366e42c54ef8f04f542f93b5a73a8ad41e60a322/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java#L415

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1686980026
PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1365075364

From bpb at openjdk.org  Thu Oct 19 15:09:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 15:09:52 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <dG8L7ZoGdumlHhpkFtoARIZ-RgTqKIsDZWqAKvo_cE8=.c42179e6-b332-4283-95e9-3ab308002fb2@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
 <dG8L7ZoGdumlHhpkFtoARIZ-RgTqKIsDZWqAKvo_cE8=.c42179e6-b332-4283-95e9-3ab308002fb2@github.com>
Message-ID: <Mtx2-F7RaCJ74g0CnJYHNX_57n-3O9rBOhN2quFdiKw=.ec44dfd5-6e41-474a-aa24-f6206848a50a@github.com>

On Thu, 19 Oct 2023 07:38:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8306308: Add some code to dispense with lock
>
> BTW: Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown?

@AlanBateman and @djelinski thanks for all the comments. I will address them and add test coverage, which I inteentionally deferred.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771141208

From lkorinth at openjdk.org  Thu Oct 19 15:16:13 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 19 Oct 2023 15:16:13 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v5]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Batch update using sed
   
   find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
   find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
   find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"
 - Merge branch '_master_jdk' into _8315097
 - explain usage
 - Revert "8315097: Rename createJavaProcessBuilder"
   
   This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
 - Revert "copyright"
   
   This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
 - Revert "fix static import"
   
   This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.
 - fix static import
 - copyright
 - 8315097: Rename createJavaProcessBuilder

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

Changes: https://git.openjdk.org/jdk/pull/15452/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=04
  Stats: 894 lines in 560 files changed: 34 ins; 10 del; 850 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From lkorinth at openjdk.org  Thu Oct 19 15:16:42 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 19 Oct 2023 15:16:42 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v4]
In-Reply-To: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>
Message-ID: <3XTw5IAFj_YpaMrqyLdO9mNbWDENFMVkwk8JBmKHDcE=.5e4b1c70-0b36-4ff5-9cce-ee4f25a8e3bb@github.com>

On Tue, 17 Oct 2023 12:29:46 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "8315097: Rename createJavaProcessBuilder"
>    
>    This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
>  - Revert "copyright"
>    
>    This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
>  - Revert "fix static import"
>    
>    This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.

If this looks roughly acceptable, I will manually add indentation spaces. I am now running tests.

The changes can be verified by running the following commands:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9 

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"

git diff HEAD f80dda8d7109c2ef6bc1f685d0b611704dec645e


Only the documentation changes should be visible.  When I have manually indented everything it should be easy to that verify that change as a whitespace-only change. But that is for tomorrow (at best).

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1771194189

From bpb at openjdk.org  Thu Oct 19 21:54:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 21:54:15 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <vFDywU0RH6dv9TVevL1UkORxE1Fzy3EeJHQVkM7l_P4=.d87005d4-55df-41f5-af27-4680339ba2e8@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
 <vFDywU0RH6dv9TVevL1UkORxE1Fzy3EeJHQVkM7l_P4=.d87005d4-55df-41f5-af27-4680339ba2e8@github.com>
Message-ID: <kK34kqLQW4-nFBaKbVzKsm7kcf0W9NgBr8qfqKAu3bc=.7c4968b9-0aab-4263-8765-356287f4e91c@github.com>

On Thu, 19 Oct 2023 07:47:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> (well, still no difference)

Likewise.

Before:

Benchmark               (capacity)   Mode  Cnt        Score        Error  Units
WriterBench.testMethod        4096  thrpt    5  7896495.475 ? 109101.117  ops/s
WriterBench.testMethod        8192  thrpt    5  3507455.124 ? 125380.018  ops/s
WriterBench.testMethod       16384  thrpt    5  1761486.228 ?  57484.438  ops/s
WriterBench.testMethod       32768  thrpt    5   897733.089 ?  88233.815  ops/s

After:

Benchmark               (capacity)   Mode  Cnt        Score        Error  Units
WriterBench.testMethod        4096  thrpt    5  7383045.614 ?  72860.403  ops/s
WriterBench.testMethod        8192  thrpt    5  4073733.378 ?  30800.651  ops/s
WriterBench.testMethod       16384  thrpt    5  1789169.956 ? 183912.728  ops/s
WriterBench.testMethod       32768  thrpt    5   848052.004 ? 113203.131  ops/s

I don't know why the measurements have such a large numerical difference however.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771756386

From bpb at openjdk.org  Thu Oct 19 22:26:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 22:26:13 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v4]
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <KjZj-0WZwWCMEZI4AbexQZdONQI8UWIT2wIiR2LGQFo=.2a6eb665-1891-4d90-8ac1-3293f2ccda3d@github.com>

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

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

  8306308: Remove obsolete comment and null checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16207/files
  - new: https://git.openjdk.org/jdk/pull/16207/files/366e42c5..cbf23b9f

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

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

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

From bpb at openjdk.org  Thu Oct 19 22:26:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 22:26:13 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <kK34kqLQW4-nFBaKbVzKsm7kcf0W9NgBr8qfqKAu3bc=.7c4968b9-0aab-4263-8765-356287f4e91c@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
 <vFDywU0RH6dv9TVevL1UkORxE1Fzy3EeJHQVkM7l_P4=.d87005d4-55df-41f5-af27-4680339ba2e8@github.com>
 <kK34kqLQW4-nFBaKbVzKsm7kcf0W9NgBr8qfqKAu3bc=.7c4968b9-0aab-4263-8765-356287f4e91c@github.com>
Message-ID: <1komKnaDQKSxKaJkFIxJ-iTpRWkUDwZSQQMebsOT5OE=.e68c4612-0a08-45ff-a18d-6af28e66a35b@github.com>

On Thu, 19 Oct 2023 21:51:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I don't know why the measurements have such a large numerical difference however.

D'oh: `ops/s` instead of `ops/ms`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771781723

From bpb at openjdk.org  Thu Oct 19 22:26:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 22:26:14 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <Oxz2lKZstA4DsaFOPc-pfgGaP-9-klTmS6xVyucch5k=.36fe4ff7-8fd6-44c4-8e07-a09aeee40e6d@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
 <Oxz2lKZstA4DsaFOPc-pfgGaP-9-klTmS6xVyucch5k=.36fe4ff7-8fd6-44c4-8e07-a09aeee40e6d@github.com>
Message-ID: <m5SYBx1yZKDpSwP-wl40FOeFkgACe5aVLkrnh1HqFHk=.f26a5804-f5d8-41b1-a3d1-bc6ed27f95a2@github.com>

On Thu, 19 Oct 2023 07:59:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8306308: Add some code to dispense with lock
>
> src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 1:
> 
>> 1: /*
> 
> There's a couple of null checks that can be removed now:
> https://github.com/openjdk/jdk/blob/366e42c54ef8f04f542f93b5a73a8ad41e60a322/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java#L393
> https://github.com/openjdk/jdk/blob/366e42c54ef8f04f542f93b5a73a8ad41e60a322/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java#L415

Removed in cbf23b9f2942a5315bc160f0f653348c0d3aeee7.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366197623

From bpb at openjdk.org  Thu Oct 19 22:26:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 22:26:14 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <dG8L7ZoGdumlHhpkFtoARIZ-RgTqKIsDZWqAKvo_cE8=.c42179e6-b332-4283-95e9-3ab308002fb2@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
 <dG8L7ZoGdumlHhpkFtoARIZ-RgTqKIsDZWqAKvo_cE8=.c42179e6-b332-4283-95e9-3ab308002fb2@github.com>
Message-ID: <qN2nfpr-yyTkDajvrcBRVHBBNTqGpsRj6POIGcG_p3Y=.6bf2917e-52e5-42fb-9ce6-dfce2b5e86cb@github.com>

On Thu, 19 Oct 2023 07:37:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8306308: Add some code to dispense with lock
>
> src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 249:
> 
>> 247:     private final int maxBufferCapacity;
>> 248: 
>> 249:     // This must be non-null
> 
> I think you can drop that comment now, it only made sense when one is non-null.

Dropped in cbf23b9f2942a5315bc160f0f653348c0d3aeee7.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366197318

From bpb at openjdk.org  Thu Oct 19 23:46:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 23:46:03 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

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

  8306308: Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16207/files
  - new: https://git.openjdk.org/jdk/pull/16207/files/cbf23b9f..24f65b6c

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

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

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

From bpb at openjdk.org  Thu Oct 19 23:46:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 23:46:04 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <dG8L7ZoGdumlHhpkFtoARIZ-RgTqKIsDZWqAKvo_cE8=.c42179e6-b332-4283-95e9-3ab308002fb2@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
 <dG8L7ZoGdumlHhpkFtoARIZ-RgTqKIsDZWqAKvo_cE8=.c42179e6-b332-4283-95e9-3ab308002fb2@github.com>
Message-ID: <xnF4TAHiaQwppVA_dcswq5MUwhiUMYDaERsE42qNc84=.bcfdcc24-9322-4bcf-9dff-dcb790e2450f@github.com>

On Thu, 19 Oct 2023 07:38:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> BTW: Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown?

The test I just added should cover this.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771844131

From bpb at openjdk.org  Thu Oct 19 23:46:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Oct 2023 23:46:04 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v3]
In-Reply-To: <s-QRsXM4_cPcSznYMsfGgHHciI3mmG6DnJoDhdR0IZ4=.3887470a-b374-40e2-9c89-1edacd0a12b4@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <Vg0bSdGwuxOGdKn7BtphwRcrK3KNBDN_LYMYdy_FVgI=.6e22ee46-9f92-40d3-b517-687c4fd2ea09@github.com>
 <dG8L7ZoGdumlHhpkFtoARIZ-RgTqKIsDZWqAKvo_cE8=.c42179e6-b332-4283-95e9-3ab308002fb2@github.com>
 <s-QRsXM4_cPcSznYMsfGgHHciI3mmG6DnJoDhdR0IZ4=.3887470a-b374-40e2-9c89-1edacd0a12b4@github.com>
Message-ID: <2vpOZ_yfxZ7rhAQMuLcOEpag59oyapwlmpvbs2O0VqQ=.a23952a3-4281-43a7-b649-cc96dbd37627@github.com>

On Thu, 19 Oct 2023 07:50:32 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> BTW: Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown?
>
>> Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown?
> 
> I don't believe we do; the code attached to the JBS ticket suggests that we did not throw, so if we had such a test, it would be failing.

The test I added is just the reproducers attached by @djelinski (thanks!) to the JDK-8306308 issue aggregated into a single JUnit 5 test. Both sub-tests fail when run against the master branch, but pass with the proposed change applied.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771846044

From djelinski at openjdk.org  Fri Oct 20 06:45:40 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 06:45:40 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
Message-ID: <HxD7jJekoddlHNvxVmlpIwXncVLfb3wL1E-HmkDpxSc=.937dce29-0aa6-4605-b18d-0ac64f50f8da@github.com>

On Thu, 19 Oct 2023 23:46:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Add test

Changes requested by djelinski (Reviewer).

` line 1:

> (failed to retrieve contents of file, check the PR for context)
This filename doesn't look good

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

PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1689336359
PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366535724

From alanb at openjdk.org  Fri Oct 20 07:28:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 07:28:40 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <HxD7jJekoddlHNvxVmlpIwXncVLfb3wL1E-HmkDpxSc=.937dce29-0aa6-4605-b18d-0ac64f50f8da@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
 <HxD7jJekoddlHNvxVmlpIwXncVLfb3wL1E-HmkDpxSc=.937dce29-0aa6-4605-b18d-0ac64f50f8da@github.com>
Message-ID: <jIF7pUCQrGj4k72OflsXBjkvaIt9oOVwdZKfqR8ryiI=.b599e5ee-05dd-4588-810d-5f058ff59c3a@github.com>

On Fri, 20 Oct 2023 06:36:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This filename doesn't look good

I think something has been fat-fingered and the test is added a second time in the root directory with a tick in the name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366578141

From lkorinth at openjdk.org  Fri Oct 20 08:34:35 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 20 Oct 2023 08:34:35 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v5]
In-Reply-To: <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>
Message-ID: <CQLu4BqqXQpv1m-Z4mKvfK890bjfytSkMMBunchwlmc=.95e9f73e-0275-4dcf-bdbb-707ce50c4902@github.com>

On Thu, 19 Oct 2023 15:16:13 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Batch update using sed
>    
>    find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
>    find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
>    find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"
>  - Merge branch '_master_jdk' into _8315097
>  - explain usage
>  - Revert "8315097: Rename createJavaProcessBuilder"
>    
>    This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
>  - Revert "copyright"
>    
>    This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
>  - Revert "fix static import"
>    
>    This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.
>  - fix static import
>  - copyright
>  - 8315097: Rename createJavaProcessBuilder

Just ignore what I just pushed, I will have a new version out

sorry...

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309579
PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309992

From alanb at openjdk.org  Fri Oct 20 10:27:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 10:27:41 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
Message-ID: <c7HfqsRP4xRyH1Vl0CKgsrevK4DJyeKPxChwbNkTZEI=.d3aa97ab-6b4e-47b6-b015-1481ebb997cc@github.com>

On Thu, 19 Oct 2023 23:46:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Add test

test/jdk/java/nio/channels/Channels/NewWriter.java line 84:

> 82:             () -> {
> 83:                 try (ServerSocket ss = new ServerSocket(0);
> 84:                      SocketChannel cs = SocketChannel.open(new InetSocketAddress(ss.getLocalPort()))) {

You probably should bind the SeverSocket to the loopback address to avoid interference from other machines.

I assume this should be "sc" (for SocketChannel) rather than "cs". The naming of the test methods looks a bit strange too, did you mean both to have an uppercase character as the first character?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366787499

From duke at openjdk.org  Fri Oct 20 11:38:40 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 20 Oct 2023 11:38:40 GMT
Subject: Withdrawn: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <x5p2cxiUOf-lSt4fUmTgnJs78qp195fQXGslzu0PSaY=.142d5d6a-9552-4ff7-9934-920bd5baa362@github.com>

On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Fri Oct 20 15:43:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 15:43:40 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <jIF7pUCQrGj4k72OflsXBjkvaIt9oOVwdZKfqR8ryiI=.b599e5ee-05dd-4588-810d-5f058ff59c3a@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
 <HxD7jJekoddlHNvxVmlpIwXncVLfb3wL1E-HmkDpxSc=.937dce29-0aa6-4605-b18d-0ac64f50f8da@github.com>
 <jIF7pUCQrGj4k72OflsXBjkvaIt9oOVwdZKfqR8ryiI=.b599e5ee-05dd-4588-810d-5f058ff59c3a@github.com>
Message-ID: <O1fvY7lsnzCpIHDgJXY7HNwV3wNLG-i5yqAnwHploas=.1cbae099-530f-47f1-840e-172baf07f9ca@github.com>

On Fri, 20 Oct 2023 07:25:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ` line 1:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> This filename doesn't look good
>
>> This filename doesn't look good
> 
> I think something has been fat-fingered and the test is added a second time in the root directory with a tick in the name.

Damn. Git was giving me problems about some untracked file and I thought I fixed. I'll look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367162079

From bpb at openjdk.org  Fri Oct 20 15:58:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 15:58:56 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v6]
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <DtO96GhhRc6oFAndhfpF4p47tvNn7EvEzfZb9vzbs3Q=.a9aaebf4-7e70-4624-b679-326d8511dea2@github.com>

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

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

  8306308: Remove spurious file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16207/files
  - new: https://git.openjdk.org/jdk/pull/16207/files/24f65b6c..68b07597

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=04-05

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

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

From alanb at openjdk.org  Fri Oct 20 16:24:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 16:24:42 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <c7HfqsRP4xRyH1Vl0CKgsrevK4DJyeKPxChwbNkTZEI=.d3aa97ab-6b4e-47b6-b015-1481ebb997cc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
 <c7HfqsRP4xRyH1Vl0CKgsrevK4DJyeKPxChwbNkTZEI=.d3aa97ab-6b4e-47b6-b015-1481ebb997cc@github.com>
Message-ID: <VCf9aKTa4uAQqeQQEAnJYHEVfhGnrZ7pybJwhL96zX4=.978a1c0e-761c-450f-91a7-d11873f46fc4@github.com>

On Fri, 20 Oct 2023 10:24:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8306308: Add test
>
> test/jdk/java/nio/channels/Channels/NewWriter.java line 84:
> 
>> 82:             () -> {
>> 83:                 try (ServerSocket ss = new ServerSocket(0);
>> 84:                      SocketChannel cs = SocketChannel.open(new InetSocketAddress(ss.getLocalPort()))) {
> 
> You probably should bind the SeverSocket to the loopback address to avoid interference from other machines.
> 
> I assume this should be "sc" (for SocketChannel) rather than "cs". The naming of the test methods looks a bit strange too, did you mean both to have an uppercase character as the first character?

I think this is close to what you want here:

        try (ServerSocket ss = new ServerSocket();
             SocketChannel sc = SocketChannel.open()) {

            InetAddress lb = InetAddress.getLoopbackAddress();
            ss.bind(new InetSocketAddress(lb, 0));
            sc.connect(ss.getLocalSocketAddress());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367216253

From bpb at openjdk.org  Fri Oct 20 16:37:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 16:37:54 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v7]
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <TCdAOIwVF3GAaOQcCvV93LJuV9Y1LXHp6pz_bJKfF74=.39c2ece4-204a-442a-9cc9-bd76bb2a2776@github.com>

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

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

  8306308: Fix test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16207/files
  - new: https://git.openjdk.org/jdk/pull/16207/files/68b07597..f1b74f08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=05-06

  Stats: 23 lines in 1 file changed: 7 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/16207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207

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

From bpb at openjdk.org  Fri Oct 20 16:37:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 16:37:55 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <O1fvY7lsnzCpIHDgJXY7HNwV3wNLG-i5yqAnwHploas=.1cbae099-530f-47f1-840e-172baf07f9ca@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
 <HxD7jJekoddlHNvxVmlpIwXncVLfb3wL1E-HmkDpxSc=.937dce29-0aa6-4605-b18d-0ac64f50f8da@github.com>
 <jIF7pUCQrGj4k72OflsXBjkvaIt9oOVwdZKfqR8ryiI=.b599e5ee-05dd-4588-810d-5f058ff59c3a@github.com>
 <O1fvY7lsnzCpIHDgJXY7HNwV3wNLG-i5yqAnwHploas=.1cbae099-530f-47f1-840e-172baf07f9ca@github.com>
Message-ID: <HnlE9kJd2-ombRrYKsk3xELWkQRAKFJIueJisz6Dc-E=.acdb3d1a-e99d-473c-a24a-7bf378042dc6@github.com>

On Fri, 20 Oct 2023 15:40:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> This filename doesn't look good
>> 
>> I think something has been fat-fingered and the test is added a second time in the root directory with a tick in the name.
>
> Damn. Git was giving me problems about some untracked file and I thought I fixed. I'll look.

I hope the finger is less fat in 68b07597a53e1271a66bea97c0fac0644dc15b7d.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367227304

From bpb at openjdk.org  Fri Oct 20 16:37:59 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 16:37:59 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <VCf9aKTa4uAQqeQQEAnJYHEVfhGnrZ7pybJwhL96zX4=.978a1c0e-761c-450f-91a7-d11873f46fc4@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
 <c7HfqsRP4xRyH1Vl0CKgsrevK4DJyeKPxChwbNkTZEI=.d3aa97ab-6b4e-47b6-b015-1481ebb997cc@github.com>
 <VCf9aKTa4uAQqeQQEAnJYHEVfhGnrZ7pybJwhL96zX4=.978a1c0e-761c-450f-91a7-d11873f46fc4@github.com>
Message-ID: <vOjk2qbsc_J1PNN0R-l0LGSRxK9o8sPyzx9FGQmJ6zM=.0f9fae33-8e00-4837-9b72-26a096e1d5d2@github.com>

On Fri, 20 Oct 2023 16:22:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Channels/NewWriter.java line 84:
>> 
>>> 82:             () -> {
>>> 83:                 try (ServerSocket ss = new ServerSocket(0);
>>> 84:                      SocketChannel cs = SocketChannel.open(new InetSocketAddress(ss.getLocalPort()))) {
>> 
>> You probably should bind the SeverSocket to the loopback address to avoid interference from other machines.
>> 
>> I assume this should be "sc" (for SocketChannel) rather than "cs". The naming of the test methods looks a bit strange too, did you mean both to have an uppercase character as the first character?
>
> I think this is close to what you want here:
> 
>         try (ServerSocket ss = new ServerSocket();
>              SocketChannel sc = SocketChannel.open()) {
> 
>             InetAddress lb = InetAddress.getLoopbackAddress();
>             ss.bind(new InetSocketAddress(lb, 0));
>             sc.connect(ss.getLocalSocketAddress());

I had already committed f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367228369

From alanb at openjdk.org  Fri Oct 20 16:45:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 16:45:32 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <vOjk2qbsc_J1PNN0R-l0LGSRxK9o8sPyzx9FGQmJ6zM=.0f9fae33-8e00-4837-9b72-26a096e1d5d2@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
 <c7HfqsRP4xRyH1Vl0CKgsrevK4DJyeKPxChwbNkTZEI=.d3aa97ab-6b4e-47b6-b015-1481ebb997cc@github.com>
 <VCf9aKTa4uAQqeQQEAnJYHEVfhGnrZ7pybJwhL96zX4=.978a1c0e-761c-450f-91a7-d11873f46fc4@github.com>
 <vOjk2qbsc_J1PNN0R-l0LGSRxK9o8sPyzx9FGQmJ6zM=.0f9fae33-8e00-4837-9b72-26a096e1d5d2@github.com>
Message-ID: <yjrRb1-55yC1Bdt3bS-OY5yohhGI5xHSIFErJpBM86w=.ed127d67-029d-4cd1-9b7f-4b2f5d431c5e@github.com>

On Fri, 20 Oct 2023 16:34:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I think this is close to what you want here:
>> 
>>         try (ServerSocket ss = new ServerSocket();
>>              SocketChannel sc = SocketChannel.open()) {
>> 
>>             InetAddress lb = InetAddress.getLoopbackAddress();
>>             ss.bind(new InetSocketAddress(lb, 0));
>>             sc.connect(ss.getLocalSocketAddress());
>
> I had already committed f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed?

> I had already committed https://github.com/openjdk/jdk/commit/f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed?

Your change binds the connecting socket, it's the listener socket that should be bound to the loopback.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367237231

From bpb at openjdk.org  Fri Oct 20 16:45:33 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 16:45:33 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <yjrRb1-55yC1Bdt3bS-OY5yohhGI5xHSIFErJpBM86w=.ed127d67-029d-4cd1-9b7f-4b2f5d431c5e@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
 <c7HfqsRP4xRyH1Vl0CKgsrevK4DJyeKPxChwbNkTZEI=.d3aa97ab-6b4e-47b6-b015-1481ebb997cc@github.com>
 <VCf9aKTa4uAQqeQQEAnJYHEVfhGnrZ7pybJwhL96zX4=.978a1c0e-761c-450f-91a7-d11873f46fc4@github.com>
 <vOjk2qbsc_J1PNN0R-l0LGSRxK9o8sPyzx9FGQmJ6zM=.0f9fae33-8e00-4837-9b72-26a096e1d5d2@github.com>
 <yjrRb1-55yC1Bdt3bS-OY5yohhGI5xHSIFErJpBM86w=.ed127d67-029d-4cd1-9b7f-4b2f5d431c5e@github.com>
Message-ID: <E5ceUjbdXEL8rIQxXXM_iZeG7s-LXzZ8iRM-Y47f4PY=.baa8b5e6-699b-4b7e-8d4f-fc1a3c5d14a6@github.com>

On Fri, 20 Oct 2023 16:40:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I had already committed f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed?
>
>> I had already committed https://github.com/openjdk/jdk/commit/f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed?
> 
> Your change binds the connecting socket, it's the listener socket that should be bound to the loopback.

Thanks, will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367241075

From bpb at openjdk.org  Fri Oct 20 16:58:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 16:58:12 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v8]
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <ZqCztKGIz2ujcCzomo70JCpaLFxzGoDu7wlZMsGWlOM=.7a18e827-ba09-4f7c-bb83-9350fb26f421@github.com>

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

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

  8306308: Really fix test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16207/files
  - new: https://git.openjdk.org/jdk/pull/16207/files/f1b74f08..850ffd6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=06-07

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

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

From bpb at openjdk.org  Fri Oct 20 16:58:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 16:58:12 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v5]
In-Reply-To: <E5ceUjbdXEL8rIQxXXM_iZeG7s-LXzZ8iRM-Y47f4PY=.baa8b5e6-699b-4b7e-8d4f-fc1a3c5d14a6@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <UVgYBdXIOybsepf8McXPIfzKRNong1Gjg0tXyAfyhj4=.0ef74ae7-0a22-402c-a9ec-1fdae42425fd@github.com>
 <c7HfqsRP4xRyH1Vl0CKgsrevK4DJyeKPxChwbNkTZEI=.d3aa97ab-6b4e-47b6-b015-1481ebb997cc@github.com>
 <VCf9aKTa4uAQqeQQEAnJYHEVfhGnrZ7pybJwhL96zX4=.978a1c0e-761c-450f-91a7-d11873f46fc4@github.com>
 <vOjk2qbsc_J1PNN0R-l0LGSRxK9o8sPyzx9FGQmJ6zM=.0f9fae33-8e00-4837-9b72-26a096e1d5d2@github.com>
 <yjrRb1-55yC1Bdt3bS-OY5yohhGI5xHSIFErJpBM86w=.ed127d67-029d-4cd1-9b7f-4b2f5d431c5e@github.com>
 <E5ceUjbdXEL8rIQxXXM_iZeG7s-LXzZ8iRM-Y47f4PY=.baa8b5e6-699b-4b7e-8d4f-fc1a3c5d14a6@github.com>
Message-ID: <ZOAP0168YWca6pY9sVKDhnMeyRPetl_mVnHwVcEiG3M=.086c2593-5097-4808-99cc-e785682bd2ea@github.com>

On Fri, 20 Oct 2023 16:42:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> I had already committed https://github.com/openjdk/jdk/commit/f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed?
>> 
>> Your change binds the connecting socket, it's the listener socket that should be bound to the loopback.
>
> Thanks, will fix.

I hope it is correct now in 850ffd6be3010a08bbcd99041a114f994f8f4993.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367261237

From djelinski at openjdk.org  Fri Oct 20 17:38:35 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 17:38:35 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v8]
In-Reply-To: <ZqCztKGIz2ujcCzomo70JCpaLFxzGoDu7wlZMsGWlOM=.7a18e827-ba09-4f7c-bb83-9350fb26f421@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <ZqCztKGIz2ujcCzomo70JCpaLFxzGoDu7wlZMsGWlOM=.7a18e827-ba09-4f7c-bb83-9350fb26f421@github.com>
Message-ID: <ONCQ8S1OvIjollvBuGd7FQ2dGrpvC64l7_0PVLIz0r0=.e5bbca40-f71e-4d76-afc2-6bcbb2ab7648@github.com>

On Fri, 20 Oct 2023 16:58:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Really fix test

test/jdk/java/nio/channels/Channels/NewWriter.java line 76:

> 74:                 writer.flush();
> 75:                 System.out.println(i);
> 76:                 actual++;

incrementing `actual` here feels weird; could you remove this, and adjust EXPECTED instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367319545

From bpb at openjdk.org  Fri Oct 20 17:47:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 17:47:37 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v8]
In-Reply-To: <ONCQ8S1OvIjollvBuGd7FQ2dGrpvC64l7_0PVLIz0r0=.e5bbca40-f71e-4d76-afc2-6bcbb2ab7648@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <ZqCztKGIz2ujcCzomo70JCpaLFxzGoDu7wlZMsGWlOM=.7a18e827-ba09-4f7c-bb83-9350fb26f421@github.com>
 <ONCQ8S1OvIjollvBuGd7FQ2dGrpvC64l7_0PVLIz0r0=.e5bbca40-f71e-4d76-afc2-6bcbb2ab7648@github.com>
Message-ID: <M1F3inAVTZjuHAFkBhw8OB84nQWwt-3QLgaOsiDd14E=.db56aded-9650-4489-87be-acbe039c7f86@github.com>

On Fri, 20 Oct 2023 17:35:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8306308: Really fix test
>
> test/jdk/java/nio/channels/Channels/NewWriter.java line 76:
> 
>> 74:                 writer.flush();
>> 75:                 System.out.println(i);
>> 76:                 actual++;
> 
> incrementing `actual` here feels weird; could you remove this, and adjust EXPECTED instead?

Yeah I think you are right; will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367327488

From bpb at openjdk.org  Fri Oct 20 17:56:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 17:56:10 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v9]
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com>

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

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

  8306308: Make EXPECTED less unexpected

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16207/files
  - new: https://git.openjdk.org/jdk/pull/16207/files/850ffd6b..d246a4b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=07-08

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

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

From djelinski at openjdk.org  Fri Oct 20 17:56:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 17:56:10 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v9]
In-Reply-To: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com>
Message-ID: <3yNuJ_dfJp3WV6AatvYhJQLHSKxYgVnkOXzKkrM92WA=.8444deb2-13c2-447e-badc-a1bd9d060e69@github.com>

On Fri, 20 Oct 2023 17:52:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Make EXPECTED less unexpected

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1690640428

From bpb at openjdk.org  Fri Oct 20 17:56:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 17:56:10 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v8]
In-Reply-To: <M1F3inAVTZjuHAFkBhw8OB84nQWwt-3QLgaOsiDd14E=.db56aded-9650-4489-87be-acbe039c7f86@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <ZqCztKGIz2ujcCzomo70JCpaLFxzGoDu7wlZMsGWlOM=.7a18e827-ba09-4f7c-bb83-9350fb26f421@github.com>
 <ONCQ8S1OvIjollvBuGd7FQ2dGrpvC64l7_0PVLIz0r0=.e5bbca40-f71e-4d76-afc2-6bcbb2ab7648@github.com>
 <M1F3inAVTZjuHAFkBhw8OB84nQWwt-3QLgaOsiDd14E=.db56aded-9650-4489-87be-acbe039c7f86@github.com>
Message-ID: <d3N5BWELbyhV8S2TIrrvxOe_xTD6lAuC3167c9qHETU=.2a01f506-f31e-4c65-8515-cf833fdb0e30@github.com>

On Fri, 20 Oct 2023 17:44:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Channels/NewWriter.java line 76:
>> 
>>> 74:                 writer.flush();
>>> 75:                 System.out.println(i);
>>> 76:                 actual++;
>> 
>> incrementing `actual` here feels weird; could you remove this, and adjust EXPECTED instead?
>
> Yeah I think you are right; will do.

Changed in d246a4b6ebfafa9d3fb15c97cffad334ff7f9f91; thanks,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367331734

From bpb at openjdk.org  Fri Oct 20 21:15:47 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 21:15:47 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v9]
In-Reply-To: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com>
Message-ID: <o5NifmOjpv37G-VlZx2qSkdpQrZLIr4unAMuEfFwlZI=.35d295d0-9cb8-4803-8540-f22493a4d602@github.com>

On Fri, 20 Oct 2023 17:56:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Make EXPECTED less unexpected

Tiers 1-3 passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1773399786

From bpb at openjdk.org  Fri Oct 20 21:15:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Oct 2023 21:15:49 GMT
Subject: Integrated: 8306308: (ch) Writer created by Channels::newWriter may
 lose data
In-Reply-To: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
Message-ID: <s--C1vWytmPyaaFNGO6xEb-cLcjBiezOQ4yAGBdXWjA=.4bc449ba-b039-412b-a6bd-5e4069716e2b@github.com>

On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.

This pull request has now been integrated.

Changeset: a1a62d99
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1a62d9964393533eeab269d1f405c8f0db1e900
Stats:     139 lines in 3 files changed: 104 ins; 22 del; 13 mod

8306308: (ch) Writer created by Channels::newWriter may lose data

Reviewed-by: djelinski, alanb

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

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

From alanb at openjdk.org  Sat Oct 21 08:41:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Oct 2023 08:41:47 GMT
Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose
 data [v9]
In-Reply-To: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com>
References: <KnwlxeEX89womBafOfKy6V4cLFQ5LeXwEhzO21x52UA=.6f679929-e2bb-4e2f-8dd8-854b797f76dc@github.com>
 <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com>
Message-ID: <jh6PsmPW90sj5holtAdBQUpD1tEDyLQXU-V7_Sp-XHA=.b8269366-c553-4210-87f9-024d2d0544b1@github.com>

On Fri, 20 Oct 2023 17:56:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306308: Make EXPECTED less unexpected

test/jdk/java/nio/channels/Channels/NewWriter.java line 96:

> 94:                     StandardCharsets.UTF_8)) {
> 95:                     for (int i = 1; i < Integer.MAX_VALUE; i++) {
> 96:                         writer.write("test" + i);

There's no need to set SO_SNDBUF here, the IBME should be thrown then the writer attempts to flush.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367690958

From pminborg at openjdk.org  Mon Oct 23 07:30:37 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Oct 2023 07:30:37 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use
 MemorySegment for file mapping [v7]
In-Reply-To: <yp3NtupNrRoZvvhJYNnI-Lj8Y9u55sDgqINTIW-Egn8=.80767e78-2b8a-4d12-af34-7ff40320824c@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
 <yp3NtupNrRoZvvhJYNnI-Lj8Y9u55sDgqINTIW-Egn8=.80767e78-2b8a-4d12-af34-7ff40320824c@github.com>
Message-ID: <RJ6jn_ibf7UiLtqMpqpZqcFJ6j-BX2Qfd9LCJ1xLhHA=.b555f962-4c7c-4bb9-b367-9cf9a2f1eb4d@github.com>

On Thu, 21 Sep 2023 16:24:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
>> 
>> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
>> 
>> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
>> 
>> Tested and passed tier1, tier2, tier3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat

Keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/15814#issuecomment-1774584634

From duke at openjdk.org  Mon Oct 23 14:43:45 2023
From: duke at openjdk.org (duke)
Date: Mon, 23 Oct 2023 14:43:45 GMT
Subject: Withdrawn: JDK-8314115: DatagramSocket.receive may hang if underlying
 UDP RCVBUF of OS is too small
In-Reply-To: <tzK13-EaY1xnDsLwh5TfFTzvCQp_iRd9HAzAheMed0c=.b62ea830-6fb3-430c-9b11-93fb3ced84d4@github.com>
References: <tzK13-EaY1xnDsLwh5TfFTzvCQp_iRd9HAzAheMed0c=.b62ea830-6fb3-430c-9b11-93fb3ced84d4@github.com>
Message-ID: <fgFLbaOAnqMdFNi0JsgU8AC-YuBpW-iga3wp-Al8GCA=.b2663456-ee22-4f62-b96e-80b6f504b4ea@github.com>

On Wed, 23 Aug 2023 11:37:23 GMT, Thomas Obermeier <duke at openjdk.org> wrote:

> docu update to explain that receive can hang because of bad configuration

This pull request has been closed without being integrated.

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

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

From lancea at openjdk.org  Mon Oct 23 19:12:57 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Oct 2023 19:12:57 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v8]
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <HxOc6Z5N0Jqgggzf9U50vJpUN6YYh6MRCcjqUcV5nIY=.3ab63812-0f96-461d-a7a2-db670966b6fe@github.com>

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

Lance Andersen 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 ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8314891
 - Add missing space
 - Revamp isZip64ExtBlockSizeValid
 - Merge branch 'master' into JDK-8314891
 - Merge branch 'master' into JDK-8314891
 - Remove tab(s) from comment
 - Added additional tests, along with additional cleanup and refactoring
 - Clean up some minor formatting issues
 - Additional Zip64 extra header validation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/208a5ecc..255aec85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15650&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15650&range=06-07

  Stats: 75854 lines in 1953 files changed: 44906 ins; 19381 del; 11567 mod
  Patch: https://git.openjdk.org/jdk/pull/15650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15650/head:pull/15650

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

From bpb at openjdk.org  Mon Oct 23 22:09:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Oct 2023 22:09:45 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of
 Channels.newWriter
Message-ID: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>

Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.

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

Commit messages:
 - 8318677: Add impl note and slightly tweak the test

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

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

From tprinzing at openjdk.org  Mon Oct 23 22:35:55 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 23 Oct 2023 22:35:55 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v2]
In-Reply-To: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
Message-ID: <lMfwUTt_PW0ITTAm-eu7hqPkAYl6l1jDUoIM8u4NKKA=.24eb3804-b952-4316-bd67-bd5eecffdf69@github.com>

> Added jar event support to socket adapters.
> 
> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java

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

  requested change to location of socket adaptor event logic
  
  bring back event offer semantics where it was fine.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16251/files
  - new: https://git.openjdk.org/jdk/pull/16251/files/05aed00a..06e35acf

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

  Stats: 123 lines in 5 files changed: 62 ins; 52 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16251/head:pull/16251

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

From alanb at openjdk.org  Tue Oct 24 06:53:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Oct 2023 06:53:36 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v2]
In-Reply-To: <lMfwUTt_PW0ITTAm-eu7hqPkAYl6l1jDUoIM8u4NKKA=.24eb3804-b952-4316-bd67-bd5eecffdf69@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <lMfwUTt_PW0ITTAm-eu7hqPkAYl6l1jDUoIM8u4NKKA=.24eb3804-b952-4316-bd67-bd5eecffdf69@github.com>
Message-ID: <5N015laYjUrZtD_doT7qPjiIIqXdkYQ7CW7T7Zmtmpo=.bb003d03-594f-4602-8e6e-5c21a0742fd6@github.com>

On Mon, 23 Oct 2023 22:35:55 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added jar event support to socket adapters.
>> 
>> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requested change to location of socket adaptor event logic
>   
>   bring back event offer semantics where it was fine.

src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 82:

> 80:         long start = SocketReadEvent.timestamp();
> 81:         int n = implRead(b, off, len);
> 82:         SocketReadEvent.offer(start, n, sc.remoteAddress(), timeoutSupplier.getAsInt());

One of the things left over from the original refactoring was to dig into my the event needs the timeout, it would be nice if that could go away.

For now, I'd prefer if the timeout could be captured once as otherwise there is no guarantee that the event will be reported with the same timeout used for the socket read. In other words, add a timeout parameter to implRead so that the method calls implRead with the timeout, avoids calling timeoutSuppler::getAsInt twice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369695891

From lkorinth at openjdk.org  Tue Oct 24 07:49:30 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 07:49:30 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:

 - static import
 - copyright
 - whitespace
 - whitespace
 - sed
 - fix test/lib/jdk/test/lib/process/ProcessTools.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/f80dda8d..2f57a32d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=04-05

  Stats: 1580 lines in 560 files changed: 44 ins; 34 del; 1502 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From alanb at openjdk.org  Tue Oct 24 08:15:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Oct 2023 08:15:38 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v2]
In-Reply-To: <lMfwUTt_PW0ITTAm-eu7hqPkAYl6l1jDUoIM8u4NKKA=.24eb3804-b952-4316-bd67-bd5eecffdf69@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <lMfwUTt_PW0ITTAm-eu7hqPkAYl6l1jDUoIM8u4NKKA=.24eb3804-b952-4316-bd67-bd5eecffdf69@github.com>
Message-ID: <rIzNOH-_LCp004O0qgvNT_9dmZUbqpjfsAyD5aTFEXI=.253e553f-40c5-49ba-8623-64923a39608a@github.com>

On Mon, 23 Oct 2023 22:35:55 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added jar event support to socket adapters.
>> 
>> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requested change to location of socket adaptor event logic
>   
>   bring back event offer semantics where it was fine.

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 68:

> 66:     public void test() throws Throwable {
> 67:         try (Recording recording = new Recording()) {
> 68:             try (ServerSocketChannel ss = ServerSocketChannel.open()) {

Did you mean to name a ServerSocketChannel "ss", other tests use "ssc".

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 74:

> 72: 
> 73:                 ss.socket().setReuseAddress(true);
> 74:                 ss.socket().bind(null);

Tests usually bind to the loopback address to reduce interference from other programs in the environment. Also ServerSocketChannel defines the bind method so you can do this:


InetAddress lb = InetAddress.getLoopbackAddress();
ssc.bind(new InetSocketAddress(lb, 0));

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 103:

> 101:                 readerThread.start();
> 102: 
> 103:                 try (SocketChannel sc = SocketChannel.open(ss.socket().getLocalSocketAddress()); Socket s = sc.socket(); OutputStream os = s.getOutputStream()) {

If you put a line break after each ; then it would be easier to read. Also you can use ssc.getLocalAddress().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369775585
PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369777836
PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369779900

From alanb at openjdk.org  Tue Oct 24 08:45:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Oct 2023 08:45:29 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter
In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
Message-ID: <kT91vFmFnO2xmrc1J9KLTKTuxXe06PEp_SDB472OcoM=.2e5811f5-bc47-4a54-a12f-2aa68328a8a0@github.com>

On Mon, 23 Oct 2023 22:03:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.

src/java.base/share/classes/java/nio/channels/Channels.java line 427:

> 425:      *
> 426:      * @implNote
> 427:      * The implementation may ignore the value of {@code minBufferCap} provided.

I think we'll need to adjust the specification of parameter too, something like "may be ignored".

For the implNote I think it can just sat that minBufferCap is ignored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16325#discussion_r1369817302

From lkorinth at openjdk.org  Tue Oct 24 09:10:43 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 09:10:43 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <U_NEwp1RAk4Dq_2OXmgi4TOR6vYQF9IVj-PU6X7-h-M=.8ee4eda5-7d48-44d7-b896-3237fae1620d@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Hi, if you want to see what I have modified manually, you can do my sed commands and compare to this pull request:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedTestJavaProcessBuilder/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createTestJvm/import static jdk.test.lib.process.ProcessTools.createTestJavaProcessBuilder/g"
git add -u; git commit -m sed

git diff-tree --no-commit-id --name-only -r 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9..HEAD | xargs sed -i -e "s%^( * Copyright (c) ....)[^[:alpha:]]*(Oracle.*)%\1, 2023, \2%"
git ls-files -m | xargs sed -i -e "s%(Copyright (c) 2023), 2023, (Oracle.*)%\1, \2%"
git add -u; git commit -m copyright

git diff HEAD 2f57a32df8d17da51a04177563327ca2a75e8061


It will give you an easier way to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1776817287

From stefank at openjdk.org  Tue Oct 24 09:51:39 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 24 Oct 2023 09:51:39 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <gQyz0Ymz5D09Wuwv4hsUjuWMSHG32Fkp_vhzQtrMAhI=.806fba1c-cc72-452e-b3d2-316b25600e3c@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1694437335

From egahlin at openjdk.org  Tue Oct 24 10:42:38 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 24 Oct 2023 10:42:38 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v2]
In-Reply-To: <5N015laYjUrZtD_doT7qPjiIIqXdkYQ7CW7T7Zmtmpo=.bb003d03-594f-4602-8e6e-5c21a0742fd6@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <lMfwUTt_PW0ITTAm-eu7hqPkAYl6l1jDUoIM8u4NKKA=.24eb3804-b952-4316-bd67-bd5eecffdf69@github.com>
 <5N015laYjUrZtD_doT7qPjiIIqXdkYQ7CW7T7Zmtmpo=.bb003d03-594f-4602-8e6e-5c21a0742fd6@github.com>
Message-ID: <SmmnDZVp-fwjpSWVU1fNpSli4VD2pYbT010l9cA1fFI=.626b6a1e-9227-4987-a4ec-f483dfcf3d00@github.com>

On Tue, 24 Oct 2023 06:50:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   requested change to location of socket adaptor event logic
>>   
>>   bring back event offer semantics where it was fine.
>
> src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 82:
> 
>> 80:         long start = SocketReadEvent.timestamp();
>> 81:         int n = implRead(b, off, len);
>> 82:         SocketReadEvent.offer(start, n, sc.remoteAddress(), timeoutSupplier.getAsInt());
> 
> One of the things left over from the original refactoring was to dig into why the event needs the timeout, it would be nice if that could go away.
> 
> For now, I'd prefer if the timeout could be captured once as otherwise there is no guarantee that the event will be reported with the same timeout used for the socket read. In other words, add a timeout parameter to implRead so that the method calls implRead with the timeout, avoids calling timeoutSuppler::getAsInt twice.

I think SocketRead.emit() have several advantages:

- No need execute remoteAddress() when the threshold don't exceed 20 ms
- Avoid the synchronized block in SocketChannelImpl::remoteAddress().
- The end time is taken more close to start time.
- One less frame for JFR to walk

The disadvantage is some code repetition, but it's not that much.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369960907

From alanb at openjdk.org  Tue Oct 24 10:54:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Oct 2023 10:54:35 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v2]
In-Reply-To: <SmmnDZVp-fwjpSWVU1fNpSli4VD2pYbT010l9cA1fFI=.626b6a1e-9227-4987-a4ec-f483dfcf3d00@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <lMfwUTt_PW0ITTAm-eu7hqPkAYl6l1jDUoIM8u4NKKA=.24eb3804-b952-4316-bd67-bd5eecffdf69@github.com>
 <5N015laYjUrZtD_doT7qPjiIIqXdkYQ7CW7T7Zmtmpo=.bb003d03-594f-4602-8e6e-5c21a0742fd6@github.com>
 <SmmnDZVp-fwjpSWVU1fNpSli4VD2pYbT010l9cA1fFI=.626b6a1e-9227-4987-a4ec-f483dfcf3d00@github.com>
Message-ID: <87839VyAwVQ6KLx0r9gBg-0AweqeTOuk3JQusUrGz_w=.1615e7c5-0a60-4c2c-96fb-a9e99ce5492b@github.com>

On Tue, 24 Oct 2023 10:40:11 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 82:
>> 
>>> 80:         long start = SocketReadEvent.timestamp();
>>> 81:         int n = implRead(b, off, len);
>>> 82:         SocketReadEvent.offer(start, n, sc.remoteAddress(), timeoutSupplier.getAsInt());
>> 
>> One of the things left over from the original refactoring was to dig into why the event needs the timeout, it would be nice if that could go away.
>> 
>> For now, I'd prefer if the timeout could be captured once as otherwise there is no guarantee that the event will be reported with the same timeout used for the socket read. In other words, add a timeout parameter to implRead so that the method calls implRead with the timeout, avoids calling timeoutSuppler::getAsInt twice.
>
> I think SocketRead.emit() have several advantages:
> 
> - No need execute remoteAddress() when the threshold don't exceed 20 ms
> - Avoid the synchronized block in SocketChannelImpl::remoteAddress().
> - The end time is taken more close to start time.
> - One less frame for JFR to walk
> 
> The disadvantage is some code repetition, but it's not that much.

If remoteAddress is an issue then we can look at that, it may be a candidate to a `@Stable` field. That is probably beyond the scope of this PR of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369973343

From bpb at openjdk.org  Tue Oct 24 16:36:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 24 Oct 2023 16:36:52 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v2]
In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
Message-ID: <UpkI8C6vrJ_u6HJ-B6LXo4fuZ6kKTUJXqwkt5whcUgM=.d430b5f5-62d7-4f4f-9833-e002b1b6953d@github.com>

> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.

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

  8318677: Adjust minBufferap verbiage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16325/files
  - new: https://git.openjdk.org/jdk/pull/16325/files/5cf432fb..5f93e577

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

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

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

From bpb at openjdk.org  Tue Oct 24 16:36:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 24 Oct 2023 16:36:53 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v2]
In-Reply-To: <kT91vFmFnO2xmrc1J9KLTKTuxXe06PEp_SDB472OcoM=.2e5811f5-bc47-4a54-a12f-2aa68328a8a0@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
 <kT91vFmFnO2xmrc1J9KLTKTuxXe06PEp_SDB472OcoM=.2e5811f5-bc47-4a54-a12f-2aa68328a8a0@github.com>
Message-ID: <ELUdOvhhk8pfL1J9j3d6IolBX3NQ9qpNonGdpKTb9Xs=.1cb47003-4a7a-4d80-82bf-99145f0a085f@github.com>

On Tue, 24 Oct 2023 08:43:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8318677: Adjust minBufferap verbiage
>
> src/java.base/share/classes/java/nio/channels/Channels.java line 427:
> 
>> 425:      *
>> 426:      * @implNote
>> 427:      * The implementation may ignore the value of {@code minBufferCap} provided.
> 
> I think we'll need to adjust the specification of parameter too, something like "may be ignored".
> 
> For the implNote I think it can just sat that minBufferCap is ignored.

Adjusted in 5f93e5776474cc286ea32963fb55bf05cf6ce22f.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16325#discussion_r1370502955

From lmesnik at openjdk.org  Tue Oct 24 17:04:41 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 24 Oct 2023 17:04:41 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <G2CSM_N-_TwMdAlZX8c-AJtweGPX39TTxuu9HXtGrbc=.1d47edf7-9d08-46ba-9e3b-3549574ebbea@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1695447658

From bpb at openjdk.org  Tue Oct 24 17:32:35 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 24 Oct 2023 17:32:35 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <pvDi2lHO4e88E6TErukEYaFu5Xj92jyiBRW-XWXaq_E=.f6aba1c7-690a-4694-a8c6-3f9a5cc6d44c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <c17K1X0TcPWbNHSDlODKtjY54K2f0V_4_n5Q8A1vdnc=.6eeae6ee-84f1-4867-ba1b-2144018e4f05@github.com>
 <pvDi2lHO4e88E6TErukEYaFu5Xj92jyiBRW-XWXaq_E=.f6aba1c7-690a-4694-a8c6-3f9a5cc6d44c@github.com>
Message-ID: <7-r1I0O4r_diSpg7h_K4qWTXWwtcIka1Offba-7i-Ks=.b8f5652a-e1b9-44c5-8d3b-4f43b1b1076b@github.com>

On Wed, 18 Oct 2023 16:20:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> A `withExtension(String ext)` could handle the common cases for removing, replacing, and adding an extension.

How would this work for the case of "compound extensions" such as `tar.gz` where one might want to end up with just `tar` or with `zip`, depending?

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1777702279

From rriggs at openjdk.org  Tue Oct 24 18:12:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 18:12:31 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <7-r1I0O4r_diSpg7h_K4qWTXWwtcIka1Offba-7i-Ks=.b8f5652a-e1b9-44c5-8d3b-4f43b1b1076b@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <c17K1X0TcPWbNHSDlODKtjY54K2f0V_4_n5Q8A1vdnc=.6eeae6ee-84f1-4867-ba1b-2144018e4f05@github.com>
 <pvDi2lHO4e88E6TErukEYaFu5Xj92jyiBRW-XWXaq_E=.f6aba1c7-690a-4694-a8c6-3f9a5cc6d44c@github.com>
 <7-r1I0O4r_diSpg7h_K4qWTXWwtcIka1Offba-7i-Ks=.b8f5652a-e1b9-44c5-8d3b-4f43b1b1076b@github.com>
Message-ID: <-n_YZl7qqvclBpEZ4aO9aYPpptcQLpOj778m0oBe-WE=.920dbee2-f20e-439a-a8e4-760f0dd25d46@github.com>

On Tue, 24 Oct 2023 17:29:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> How would this work for the case of "compound extensions" such as `tar.gz` where one might want to end up with just `tar` or with `zip`, depending?

I'd view that a sequence of extensions so it would take a double application of withExtension to replace both. I.e.


   Path path = Path.of("photos.tar.gz");
   Path newP = path.withExtension("") // remove .gz; if there was no extension it would return the base
        .withExtension(".zip");   -> "photos.zip"

// Testing for a compound extension
   if (path.getExtension().equals("gz") && path.withExtension("").getExtension().equals("tar")) {...} 

// Switching from zip to tar.gz is easier; It removes one extension and adds the string.
  path.withExtension("tar.gz");

// Alternatively revert to old ways; no real help in this case.
    path.filename().endsWith(".tar.gz");

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1777765764

From rriggs at openjdk.org  Tue Oct 24 19:42:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 19:42:43 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <6qyfRp98A2DA7Q7YhscmdmokkIvVVn9HxB_XjRdM47g=.615d7a65-e109-41db-b955-31c0a934debd@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

test/lib/jdk/test/lib/process/ProcessTools.java line 506:

> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List<String> command) {
> 506:         return createTestJavaProcessBuilder(command.toArray(String[]::new));

The javadoc shoul d describe all of the options being added to the ProcessBuilder.
They were inadequated described previously and still are.
The other options (seem to be from the code), test.noclasspath, java.class.path, and test.thread.factory.
The description of test.thread.factory and addTestThreadFactoryArgs method seems inadequately described.

test/lib/jdk/test/lib/process/ProcessTools.java line 527:

> 525:      * Create ProcessBuilder using the java launcher from the jdk to
> 526:      * be tested.
> 527:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for `reateTestJavaProcessBuilder(...)`

test/lib/jdk/test/lib/process/ProcessTools.java line 549:

> 547:      * Create ProcessBuilder using the java launcher from the jdk to
> 548:      * be tested.
> 549:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for reateTestJavaProcessBuilder(...)

test/lib/jdk/test/lib/process/ProcessTools.java line 599:

> 597:      */
> 598:     public static OutputAnalyzer executeTestJvm(String... cmds) throws Exception {
> 599:         ProcessBuilder pb = createTestJavaProcessBuilder(cmds);

This should also describe *all* of the options being set in the ProcessBuilder before executing the process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370728371
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729609
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729925
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370730637

From alanb at openjdk.org  Tue Oct 24 19:44:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Oct 2023 19:44:35 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v2]
In-Reply-To: <UpkI8C6vrJ_u6HJ-B6LXo4fuZ6kKTUJXqwkt5whcUgM=.d430b5f5-62d7-4f4f-9833-e002b1b6953d@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
 <UpkI8C6vrJ_u6HJ-B6LXo4fuZ6kKTUJXqwkt5whcUgM=.d430b5f5-62d7-4f4f-9833-e002b1b6953d@github.com>
Message-ID: <cYC9BmujYVATvtujTYLXhyY9PlXBv02YKiwt71Rn7tE=.b43f83a7-d735-4273-b43e-7956224a00b7@github.com>

On Tue, 24 Oct 2023 16:36:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8318677: Adjust minBufferap verbiage

I think this is okay. Given that the spec is extended to allow for the ignore case then I think a CSR will be needed.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16325#pullrequestreview-1695753249

From bpb at openjdk.org  Tue Oct 24 23:25:47 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 24 Oct 2023 23:25:47 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v3]
In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
Message-ID: <lzQtB8Dt5AcTzIpuCr-608MLzg1bwDRwNGfjw6zHzlw=.5247960c-b96d-4d2b-bddc-2d31764c1370@github.com>

> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.

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

  8318677: Correct the faux pas of the previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16325/files
  - new: https://git.openjdk.org/jdk/pull/16325/files/5f93e577..60ba5c0f

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

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

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

From stefank at openjdk.org  Wed Oct 25 07:27:32 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Oct 2023 07:27:32 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <CZcrmy99xK8GvWF8BD1TmmM_Q8F0po6d3zExg2zNtSY=.9d126ffd-f3ad-4257-a0e4-0a83e3e17a47@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
 <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>
 <CZcrmy99xK8GvWF8BD1TmmM_Q8F0po6d3zExg2zNtSY=.9d126ffd-f3ad-4257-a0e4-0a83e3e17a47@github.com>
Message-ID: <BYTPUH_b0INyCGVwslaQVyQkTYKNOQvJfnLhKv6mlLM=.bbd8a311-3af8-4288-9491-55c8098af7c8@github.com>

On Tue, 5 Sep 2023 18:05:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name.
>> 
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases.
>
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca
> 
> The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name.
> 
> There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added.
> @AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process.
> Every test writer should be aware that additional command line options may be mixed in.
> 
> There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures.
> 
> As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change.

@RogerRiggs You seem to know what you want w.r.t. the extra java doc comments. Could you help write those? Could we also do that as a separate RFE? I think that would make it easier to get this PR and the javadoc update through the door.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1778669353

From lkorinth at openjdk.org  Wed Oct 25 08:44:29 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 25 Oct 2023 08:44:29 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

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

  fix copyright year and indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/2f57a32d..4cc3865a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=05-06

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

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

From rriggs at openjdk.org  Wed Oct 25 13:28:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Oct 2023 13:28:32 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v3]
In-Reply-To: <lzQtB8Dt5AcTzIpuCr-608MLzg1bwDRwNGfjw6zHzlw=.5247960c-b96d-4d2b-bddc-2d31764c1370@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
 <lzQtB8Dt5AcTzIpuCr-608MLzg1bwDRwNGfjw6zHzlw=.5247960c-b96d-4d2b-bddc-2d31764c1370@github.com>
Message-ID: <0ACuC1BvhVg_63ePHjoTM4ury9etseIOVLgJvV3odOE=.19adc30d-ab35-4b83-8023-166463504943@github.com>

On Tue, 24 Oct 2023 23:25:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8318677: Correct the faux pas of the previous commit

src/java.base/share/classes/java/nio/channels/Channels.java line 538:

> 536:      *         The minimum capacity of the internal byte buffer,
> 537:      *         or {@code -1} if an implementation-dependent
> 538:      *         default capacity is to be used; may be ignored

I'm not understanding this. The implNote says it *is* ignored, the annotation on the @param says *may*.


     *         The minimum capacity of the internal byte buffer,
     *         or {@code -1} if an implementation-dependent default capacity is to be used.
     *         The minimum capacity is ignored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16325#discussion_r1371758054

From alanb at openjdk.org  Wed Oct 25 13:28:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Oct 2023 13:28:33 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v3]
In-Reply-To: <0ACuC1BvhVg_63ePHjoTM4ury9etseIOVLgJvV3odOE=.19adc30d-ab35-4b83-8023-166463504943@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
 <lzQtB8Dt5AcTzIpuCr-608MLzg1bwDRwNGfjw6zHzlw=.5247960c-b96d-4d2b-bddc-2d31764c1370@github.com>
 <0ACuC1BvhVg_63ePHjoTM4ury9etseIOVLgJvV3odOE=.19adc30d-ab35-4b83-8023-166463504943@github.com>
Message-ID: <Yw3mEyB8gjRdSWQ0EKD8c14-NUcKYvYBO39Qt4cAgFI=.8ee65fbd-d135-4b09-9cdd-29766dd096e8@github.com>

On Wed, 25 Oct 2023 13:24:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8318677: Correct the faux pas of the previous commit
>
> src/java.base/share/classes/java/nio/channels/Channels.java line 538:
> 
>> 536:      *         The minimum capacity of the internal byte buffer,
>> 537:      *         or {@code -1} if an implementation-dependent
>> 538:      *         default capacity is to be used; may be ignored
> 
> I'm not understanding this. The implNote says it *is* ignored, the annotation on the @param says *may*.
> 
> 
>      *         The minimum capacity of the internal byte buffer,
>      *         or {@code -1} if an implementation-dependent default capacity is to be used.
>      *         The minimum capacity is ignored.

> I'm not understanding this. The implNote says it _is_ ignored, the annotation on the @param says _may_.

The spec allows the value to be ignored, the JDK implementation ignores the value. So it's spec vs. implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16325#discussion_r1371761296

From tprinzing at openjdk.org  Wed Oct 25 21:43:54 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 25 Oct 2023 21:43:54 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v3]
In-Reply-To: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
Message-ID: <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>

> Added jar event support to socket adapters.
> 
> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java

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

  changes from review:
  
  - use loopback address
  - fetch timeout once
  - formatting improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16251/files
  - new: https://git.openjdk.org/jdk/pull/16251/files/06e35acf..625fc6a5

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

  Stats: 18 lines in 2 files changed: 8 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16251/head:pull/16251

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

From rriggs at openjdk.org  Wed Oct 25 22:00:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Oct 2023 22:00:31 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <qyv3_2FCcacwbDL17B7JewcsR5XazNJjio3Z_WNTq_U=.88ec5e8f-7929-443c-a85f-617260b584e4@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Suggestions to complete the descriptions of the createXXXJavaProcessBuilder methods.

test/lib/jdk/test/lib/process/ProcessTools.java line 505:

> 503:      * @return The ProcessBuilder instance representing the java command.
> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List<String> command) {

Include the same description of other properties that are included in creating the ProcessBuilder...
```     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 520:

> 518:      * @return The ProcessBuilder instance representing the java command.
> 519:      */
> 520:     public static ProcessBuilder createTestJavaProcessBuilder(String... command) {

Include the same description of other properties that are included in creating the ProcessBuilder...

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 538:

> 536:      * it in combination with <b>@requires vm.flagless</b> JTREG
> 537:      * anotation as to not waste energy and test resources.
> 538:      *

Consider adding this description of what this method does.
Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 560:

> 558:      * it in combination with <b>@requires vm.flagless</b> JTREG
> 559:      * anotation as to not waste energy and test resources.
> 560:      *

Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1698308785
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364800
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364171
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372361862
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372362333

From dfuchs at openjdk.org  Thu Oct 26 10:36:36 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Oct 2023 10:36:36 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v3]
In-Reply-To: <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>
Message-ID: <zjg8NQKtMKp7lkZ-DRVEkpIwt7V3B2U7RhP2MkzQq4I=.da89ded7-8dc8-4f1b-95f0-9cef8f1e2cae@github.com>

On Wed, 25 Oct 2023 21:43:54 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added jar event support to socket adapters.
>> 
>> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes from review:
>   
>   - use loopback address
>   - fetch timeout once
>   - formatting improvements

Looks good to me. I like the use of `offer` to reduce the boiler-plate code, when acquiring the event parameters doesn't cause any allocation and just return some field value.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16251#pullrequestreview-1699265942

From alanb at openjdk.org  Thu Oct 26 10:39:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Oct 2023 10:39:35 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v3]
In-Reply-To: <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>
Message-ID: <qaaEkcTnioreRz-LNcBYpWVrD7tR-wplD5WE-x5MORI=.288cadaf-1fbc-4a35-93a9-3b8d67b85dfd@github.com>

On Wed, 25 Oct 2023 21:43:54 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added jar event support to socket adapters.
>> 
>> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes from review:
>   
>   - use loopback address
>   - fetch timeout once
>   - formatting improvements

src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022,2023 Oracle and/or its affiliates. All rights reserved.

I think the Oracle copyright header checker will ask you to put a space after the comma.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372950705

From alanb at openjdk.org  Thu Oct 26 10:44:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Oct 2023 10:44:35 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v3]
In-Reply-To: <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>
Message-ID: <9PEFM0H6vsuBSjolf4Mwp-8qf_wDC2gygQaa80SW-LY=.a8a11150-3695-469e-9694-96b9f002768f@github.com>

On Wed, 25 Oct 2023 21:43:54 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added jar event support to socket adapters.
>> 
>> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes from review:
>   
>   - use loopback address
>   - fetch timeout once
>   - formatting improvements

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 497:

> 495:         long start = SocketReadEvent.timestamp();
> 496:         int nbytes = implRead(buf);
> 497:         SocketReadEvent.offer(start, nbytes, remoteAddress(), 0);

I don't have a strong opinion on shouldCommit+emit vs. offer, both are readable at the use sites. If we go with what you have then we'll need to look into making remoteAddress a stable field.

src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 83:

> 81:         int n = implRead(b, off, len, timeout);
> 82:         SocketReadEvent.offer(start, n, sc.remoteAddress(), timeout);
> 83:         return n;

This is better, it means that the event is guaranteed to use the same timeout as the read operation.

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 75:

> 73:                 recording.start();
> 74: 
> 75:                 ssc.socket().setReuseAddress(true);

No need for setReuseAddress here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372953644
PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372954447
PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372956024

From alanb at openjdk.org  Thu Oct 26 10:50:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Oct 2023 10:50:35 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v3]
In-Reply-To: <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <YjerO4FJxciiQLn0QSyQEy1j1wwpaporGNBRxwOtdRk=.014771b4-593a-4cba-981d-ae0df3bb38f4@github.com>
Message-ID: <T6IX4banFIjn4JN_gDZIj3CrubcC0CcHHUmn3SEoEAc=.531f1e6a-dea8-4a9a-ba08-a472420ce93e@github.com>

On Wed, 25 Oct 2023 21:43:54 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added jar event support to socket adapters.
>> 
>> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes from review:
>   
>   - use loopback address
>   - fetch timeout once
>   - formatting improvements

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 48:

> 46: 
> 47: /**
> 48:  * @test

It might be useful to have the `@bug` tag to link to JDK-8310978.

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 91:

> 89: 
> 90:                             int bytesRead = is.read(bs, 0, 3);
> 91:                             assertEquals(bytesRead, 3, "Wrong bytesRead partial buffer");

This is probably okay although in theory the read method may return 1 or 2 bytes here. Initially I thought you should be using readNBytes here but that may involve more than one read and thus disrupt the number of events expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372962518
PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372961460

From lkorinth at openjdk.org  Thu Oct 26 15:33:38 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 26 Oct 2023 15:33:38 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <CZyt2tGATgYnxwwXcRUx-f2W4UTwCRouztmSTtinrTw=.6dc482ad-77ad-4d75-94ab-0ae273d0a2a8@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Would it be okay if we handle the new method documentation in a separate pull request? 

After applying your changes, I also noted that the existing description `The command line will be like: {test.jdk}/bin/java {test.vm.opts} {test.java.opts} cmds` is not only incorrect (or at least incomplete), but now also clashes with the added description. I then removed the sentence, but after I did that I also found out that similar wording exist in `executeTestJvm` and I fear that if I continue to pull strings, I will create more and more changes that you will have opinions on.

Is it all right if we push what we have now, and that I create a new pull requests with these improvements in documentation that are actually not related to the changes in this pull request?

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1781359450

From rriggs at openjdk.org  Thu Oct 26 16:29:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Oct 2023 16:29:40 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <Yx-2Zuy3fBrCV9jiHIiGJSLOBBy7Hv9BVRBeB1ytvLk=.e3026827-3141-4ee4-b8ea-2d459d42eabf@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

ok, to correct the javadoc in a subsequent PR.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1700061972

From bpb at openjdk.org  Thu Oct 26 20:43:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 26 Oct 2023 20:43:04 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v4]
In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
Message-ID: <IE4snBGFD-cpskzPBLWPrP9exOgrs7KSvBqCWWEUUi8=.9b6b5f1f-50c5-432d-92fd-63f7e7c462d4@github.com>

> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.

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

  8318677: Improve the clarity of the spec of minBufferCap in newWriter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16325/files
  - new: https://git.openjdk.org/jdk/pull/16325/files/60ba5c0f..a48c2ece

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

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

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

From rriggs at openjdk.org  Thu Oct 26 20:43:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Oct 2023 20:43:04 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v4]
In-Reply-To: <IE4snBGFD-cpskzPBLWPrP9exOgrs7KSvBqCWWEUUi8=.9b6b5f1f-50c5-432d-92fd-63f7e7c462d4@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
 <IE4snBGFD-cpskzPBLWPrP9exOgrs7KSvBqCWWEUUi8=.9b6b5f1f-50c5-432d-92fd-63f7e7c462d4@github.com>
Message-ID: <AzXBCll8hfdmlyNrzsm1WHY8Pz4aDVMmQOtUXkLPBtU=.83a4be9d-ae92-4324-b220-b13b16ec642b@github.com>

On Thu, 26 Oct 2023 20:38:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8318677: Improve the clarity of the spec of minBufferCap in newWriter

Thanks for the clarification.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16325#pullrequestreview-1700604502

From bpb at openjdk.org  Thu Oct 26 20:47:32 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 26 Oct 2023 20:47:32 GMT
Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant
 of Channels.newWriter [v2]
In-Reply-To: <cYC9BmujYVATvtujTYLXhyY9PlXBv02YKiwt71Rn7tE=.b43f83a7-d735-4273-b43e-7956224a00b7@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
 <UpkI8C6vrJ_u6HJ-B6LXo4fuZ6kKTUJXqwkt5whcUgM=.d430b5f5-62d7-4f4f-9833-e002b1b6953d@github.com>
 <cYC9BmujYVATvtujTYLXhyY9PlXBv02YKiwt71Rn7tE=.b43f83a7-d735-4273-b43e-7956224a00b7@github.com>
Message-ID: <SncO9toS-Qw_WjxfyBA65PW_bqQAAuCTWeHka0s4PBY=.0529891f-140d-4541-b6f8-fefdbc02aecf@github.com>

On Tue, 24 Oct 2023 19:42:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think this is okay. Given that the spec is extended to allow for the ignore case then I think a CSR will be needed.

I clarified the verbiage slightly in a48c2ece4f9e8eeb5e8521a3ff4602c54a4596d7. The CSR changed identically but was not moved back to draft.

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

PR Comment: https://git.openjdk.org/jdk/pull/16325#issuecomment-1781869554

From lkorinth at openjdk.org  Fri Oct 27 08:50:47 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 08:50:47 GMT
Subject: Integrated: 8315097: Rename createJavaProcessBuilder
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <n5Oky40OR8ZXdkJbSQiivcZCzZ6XP12wnJEWzcY4xYw=.d997c70c-cae2-4bf3-9d83-2f24d1cbcb22@github.com>

On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

This pull request has now been integrated.

Changeset: d52a995f
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d52a995f35de26c2cc4074297a75141e4a363e1b
Stats:     1574 lines in 560 files changed: 44 ins; 10 del; 1520 mod

8315097: Rename createJavaProcessBuilder

Reviewed-by: lmesnik, dholmes, rriggs, stefank

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

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

From lkorinth at openjdk.org  Fri Oct 27 09:00:48 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 09:00:48 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <b2XfkO_Ez_LuJQZffSPp63wciX1NImzAD5l3Xy1elOU=.48bdc440-238c-4a86-b8b8-c2f37e2277a7@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Thanks, see:
https://bugs.openjdk.org/browse/JDK-8318962

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1782552641

From bpb at openjdk.org  Fri Oct 27 18:57:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 27 Oct 2023 18:57:57 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v3]
In-Reply-To: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
Message-ID: <8_HnEiptmAz7kAiau9kJ0qVm7KDIsVE1OmWM-hg9w-Y=.378b6d68-9e1f-4148-82b3-32ca49a5366a@github.com>

> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list,

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge
 - 8315273: Add bug ID to test
 - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15525/files
  - new: https://git.openjdk.org/jdk/pull/15525/files/a632bd88..dd3ce6d1

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

  Stats: 176389 lines in 4907 files changed: 85553 ins; 41171 del; 49665 mod
  Patch: https://git.openjdk.org/jdk/pull/15525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15525/head:pull/15525

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

From tprinzing at openjdk.org  Fri Oct 27 19:26:48 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Fri, 27 Oct 2023 19:26:48 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v4]
In-Reply-To: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
Message-ID: <AK-soDJ_uN3alKKnPOOElA3Kcm9f4E_XE8mBBP4C2V8=.c3e6641a-a053-4461-9b66-600dc9d99d02@github.com>

> Added jfr event support to socket adapters.
> 
> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java

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

  various fixups:
  
  - propagate TestSocketAdaptorEvents changes to TestSocketEvents and
    TestSocketChannelEvents.
  - copyright fixups
  - additional test tags

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16251/files
  - new: https://git.openjdk.org/jdk/pull/16251/files/625fc6a5..4b0daa5e

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

  Stats: 20 lines in 5 files changed: 8 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16251/head:pull/16251

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

From alanb at openjdk.org  Sat Oct 28 16:39:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 28 Oct 2023 16:39:33 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v4]
In-Reply-To: <AK-soDJ_uN3alKKnPOOElA3Kcm9f4E_XE8mBBP4C2V8=.c3e6641a-a053-4461-9b66-600dc9d99d02@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <AK-soDJ_uN3alKKnPOOElA3Kcm9f4E_XE8mBBP4C2V8=.c3e6641a-a053-4461-9b66-600dc9d99d02@github.com>
Message-ID: <8sl8xHJhjYSGJMdnw-ual0IOa7OFrIqoFIowOULZ2t0=.99312a6d-665f-4eb8-829f-2ccad9a3d67a@github.com>

On Fri, 27 Oct 2023 19:26:48 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added jfr event support to socket adapters.
>> 
>> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   various fixups:
>   
>   - propagate TestSocketAdaptorEvents changes to TestSocketEvents and
>     TestSocketChannelEvents.
>   - copyright fixups
>   - additional test tags

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16251#pullrequestreview-1702815697

From alanb at openjdk.org  Sun Oct 29 17:45:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 29 Oct 2023 17:45:32 GMT
Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops [v4]
In-Reply-To: <AK-soDJ_uN3alKKnPOOElA3Kcm9f4E_XE8mBBP4C2V8=.c3e6641a-a053-4461-9b66-600dc9d99d02@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
 <AK-soDJ_uN3alKKnPOOElA3Kcm9f4E_XE8mBBP4C2V8=.c3e6641a-a053-4461-9b66-600dc9d99d02@github.com>
Message-ID: <2p2-CaNYM3k4llWW8Hv4XjS1QtAPXVb_LO6no6YXb1Q=.056231b6-18a6-4802-8c90-69fcefafcaac@github.com>

On Fri, 27 Oct 2023 19:26:48 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added jfr event support to socket adapters.
>> 
>> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   various fixups:
>   
>   - propagate TestSocketAdaptorEvents changes to TestSocketEvents and
>     TestSocketChannelEvents.
>   - copyright fixups
>   - additional test tags

> /integrate

I can sponsor but your branch is more than 2 weeks behind main line so I will need to test it in the CI first.

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

PR Comment: https://git.openjdk.org/jdk/pull/16251#issuecomment-1784179678

From tprinzing at openjdk.org  Mon Oct 30 06:07:47 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 30 Oct 2023 06:07:47 GMT
Subject: Integrated: 8310978: JFR events SocketReadEvent/SocketWriteEvent for
 Socket adaptor ops
In-Reply-To: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
References: <Kl_UKCheM3OJICBaHezxdWlQDCOKPr_6yriv3yLTUnI=.92b1f351-5743-4bcf-9342-ef1d2789cd79@github.com>
Message-ID: <5v9Y1gOvnt77LDa3Fx1Y_crAG0sUyWkVIn4nSyfu5gU=.30ba0a45-475c-434b-b58b-1dcba99b187e@github.com>

On Wed, 18 Oct 2023 18:00:40 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Added jfr event support to socket adapters.
> 
> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java

This pull request has now been integrated.

Changeset: 1183b221
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1183b221c2e15d6b6c8504ca9a71a5f2050a8c15
Stats:     218 lines in 8 files changed: 188 ins; 14 del; 16 mod

8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops

Reviewed-by: dfuchs, alanb

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

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

From bpb at openjdk.org  Mon Oct 30 18:30:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Oct 2023 18:30:44 GMT
Subject: Integrated: 8318677: (ch) Add implNote about minBufferCap to main
 variant of Channels.newWriter
In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com>
Message-ID: <qJ_eck8qyOpw2ANHxdEnyhRyfjUNBkiczn8dQzEzR98=.266f0197-2b91-4b74-ab1d-72c5f7eaa865@github.com>

On Mon, 23 Oct 2023 22:03:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test.

This pull request has now been integrated.

Changeset: d3534b08
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3534b08b5691c362db987f207da7cdd9c3b4b5a
Stats:     7 lines in 2 files changed: 4 ins; 1 del; 2 mod

8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter

Reviewed-by: alanb, rriggs

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

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

From bpb at openjdk.org  Mon Oct 30 21:10:33 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Oct 2023 21:10:33 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <Sz1jC3VIIc7ocuXrL_rp-qh9UcK9kH5-W61zZFGxeC0=.6bbd4a27-c8b2-44d8-97b9-917488825030@github.com>

On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

This request could be reformulated as a list of three different topics:

1. the definition of a filename extension;
2. the extraction of the filename extension from a `Path`; and
3. the manipulation of the filename extension of a `Path` (to produce another `Path`).

The contention thus far is centered around the third item and I conjecture that the first two items likely have a good level of consensus. I winder therefore whether it might be better to break this proposal into two proposals, the first consisting of the the first two items in the list, and the second of the third item.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1786047732