From serb at openjdk.org  Thu Jan  1 04:24:24 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 1 Jan 2026 04:24:24 GMT
Subject: Withdrawn: 8374320: Update copyright year to 2025 for java.net.http in
 files where it was missed
In-Reply-To: <i1BM1nHJu2w611rqvMcufkN4_ommsmNTzqCAoH6ZoI0=.82c59e6f-53ac-47c9-8f00-aa6db1c0f93d@github.com>
References: <i1BM1nHJu2w611rqvMcufkN4_ommsmNTzqCAoH6ZoI0=.82c59e6f-53ac-47c9-8f00-aa6db1c0f93d@github.com>
Message-ID: <zYIlVtcK68eED3BdTEfHQQl4ow1lpsna9z9Ozp5zGwE=.a8399be1-3dc7-47df-9942-0887d23da6d8@github.com>

On Wed, 24 Dec 2025 02:05:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "java.net.http" files updated in 2025 has been bumped to 2025. All files are updated which touched the src/java.net.http and related files.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `
> git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

This pull request has been closed without being integrated.

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

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

From fmeum at openjdk.org  Thu Jan  1 06:53:42 2026
From: fmeum at openjdk.org (Fabian Meumertzheim)
Date: Thu, 1 Jan 2026 06:53:42 GMT
Subject: RFR: 8374441: FileSystemProvider.readAttributesIfExists should return
 null for ENOTDIR (unix)
Message-ID: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>

`FileSystemProvider.readAttributesIfExists` now returns `null` for paths with a true prefix that is not a directory rather than throwing `NotDirectoryException`.

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

Commit messages:
 - 8374441: FileSystemProvider.readAttributesIfExists should return null for ENOTDIR (unix)

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

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

From alanb at openjdk.org  Thu Jan  1 07:53:13 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jan 2026 07:53:13 GMT
Subject: Integrated: 8374382: (aio) AsynchronousFileChannel writes wrong
 content using heap ByteBuffer when position != 0
In-Reply-To: <QouuuN5mhKnY0-u_ju-4SvQ5oMcZso3w3qWoepS9RR0=.8362c108-ec86-4f4a-85f6-71c9dd83bd25@github.com>
References: <QouuuN5mhKnY0-u_ju-4SvQ5oMcZso3w3qWoepS9RR0=.8362c108-ec86-4f4a-85f6-71c9dd83bd25@github.com>
Message-ID: <r-VnK1l77_lEjeY481Zzk5mgift2JIpRdFnQNCH3vZY=.34863b94-a0b3-4006-b9ba-7bea41d972e5@github.com>

On Wed, 31 Dec 2025 07:08:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> On Windows only, if AsynchronousFileChannel is used with a heap ByteBuffer with a non-0 buffer position then the AsynchronousFileChannel read/write methods don't work correctly when the buffer is "substituted" for the underlying I/O operation.
> 
> This is a regression in JDK 26 after JDK-8357847, missed as we didn't have tests that exercise this scenario.

This pull request has now been integrated.

Changeset: d9bd300c
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08
Stats:     191 lines in 2 files changed: 189 ins; 0 del; 2 mod

8374382: (aio) AsynchronousFileChannel writes wrong content using heap ByteBuffer when position != 0

Reviewed-by: jpai

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

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

From fmeum at openjdk.org  Thu Jan  1 17:23:52 2026
From: fmeum at openjdk.org (Fabian Meumertzheim)
Date: Thu, 1 Jan 2026 17:23:52 GMT
Subject: RFR: 8374441: FileSystemProvider.readAttributesIfExists should
 return null for ENOTDIR (unix)
In-Reply-To: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
Message-ID: <CL2HZxJt2h_8hBW_GqW4SFeD0fwL0GEQNBxM1KNtueo=.75cbf8a3-97dc-48dc-9655-a4cf9bdcf0e6@github.com>

On Wed, 31 Dec 2025 21:14:29 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.

The linux-x64 debug build job consistently fails with "No space left on device", which doesn't appear to be related to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/29013#issuecomment-3703922943

From alanb at openjdk.org  Fri Jan  2 07:09:51 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Jan 2026 07:09:51 GMT
Subject: RFR: 8374441: FileSystemProvider.readAttributesIfExists should
 return null for ENOTDIR (unix)
In-Reply-To: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
Message-ID: <9gJrARkc90ok91ShPMFlnwC2vDyMoXy6S6pkqpWit4s=.83195f51-8d67-4f51-9269-c67ab74d17c2@github.com>

On Wed, 31 Dec 2025 21:14:29 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.

FileSystemProvider.readAttributesIfExists is part of the SPI so should be rare to see a direct usage. Instead, the usages are indirect, e.g. Files.isXXX to avoid using exceptions for control flow. Would it be possible to update the JBS issue or this PR with a some context as to how you ran into this. The implementation of APIs such as Files.isXXX will already handle the FileSystemException so the change should be transparent. I'm wondering if we've missed something in another usage (of some API) that causes the FileSystemException to surface.

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

PR Comment: https://git.openjdk.org/jdk/pull/29013#issuecomment-3704640027

From alanb at openjdk.org  Fri Jan  2 07:35:11 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Jan 2026 07:35:11 GMT
Subject: [jdk26] RFR: 8374382: (aio) AsynchronousFileChannel writes wrong
 content using heap ByteBuffer when position != 0
Message-ID: <Z86WaZTcNomQ0jNighhXvxGHOz7ot13eyv13ZER9FII=.84a4d7de-45cb-492a-8f33-99975e0f03b2@github.com>

This pull request contains a clean backport of changeset https://github.com/openjdk/jdk/commit/d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

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

Commit messages:
 - Backport d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08

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

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

From jpai at openjdk.org  Fri Jan  2 07:41:51 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 2 Jan 2026 07:41:51 GMT
Subject: [jdk26] RFR: 8374382: (aio) AsynchronousFileChannel writes wrong
 content using heap ByteBuffer when position != 0
In-Reply-To: <Z86WaZTcNomQ0jNighhXvxGHOz7ot13eyv13ZER9FII=.84a4d7de-45cb-492a-8f33-99975e0f03b2@github.com>
References: <Z86WaZTcNomQ0jNighhXvxGHOz7ot13eyv13ZER9FII=.84a4d7de-45cb-492a-8f33-99975e0f03b2@github.com>
Message-ID: <5XyCwu5Nji_X7LnqASm-irnkXqoZWAKVV6ccD5-7wj8=.9583b2e2-486a-448f-b7ac-4074101170c8@github.com>

On Fri, 2 Jan 2026 06:58:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This pull request contains a clean backport of changeset https://github.com/openjdk/jdk/commit/d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29015#pullrequestreview-3622380585

From fmeum at openjdk.org  Fri Jan  2 11:42:01 2026
From: fmeum at openjdk.org (Fabian Meumertzheim)
Date: Fri, 2 Jan 2026 11:42:01 GMT
Subject: RFR: 8374441: FileSystemProvider.readAttributesIfExists should
 return null for ENOTDIR (unix)
In-Reply-To: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
Message-ID: <DsaLHcBdyP3qSmbceQNoOjCdRlALbkVwySFhHuNoUCc=.2ee60879-8d8a-4b42-81c0-bb778f3660c6@github.com>

On Wed, 31 Dec 2025 21:14:29 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.

I added more details to the JBS issue. Bazel would like to use the provider method directly so that it doesn't have to pay for the cost of an exception in the case where a file does not exist, but our tests show that the method still throws in some edge cases in which the file is considered missing by higher-level APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/29013#issuecomment-3705149978

From alanb at openjdk.org  Sat Jan  3 06:29:01 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Jan 2026 06:29:01 GMT
Subject: [jdk26] Integrated: 8374382: (aio) AsynchronousFileChannel writes
 wrong content using heap ByteBuffer when position != 0
In-Reply-To: <Z86WaZTcNomQ0jNighhXvxGHOz7ot13eyv13ZER9FII=.84a4d7de-45cb-492a-8f33-99975e0f03b2@github.com>
References: <Z86WaZTcNomQ0jNighhXvxGHOz7ot13eyv13ZER9FII=.84a4d7de-45cb-492a-8f33-99975e0f03b2@github.com>
Message-ID: <vD4FhQfLcbXXjrR01HItyx-SJ7BU8H0JSGdT839GKeg=.b19d0952-f735-4ede-b033-7eb0e6175005@github.com>

On Fri, 2 Jan 2026 06:58:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This pull request contains a clean backport of changeset https://github.com/openjdk/jdk/commit/d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This pull request has now been integrated.

Changeset: 6950503d
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6950503dcf786e875a75c76141759e24ac46c3f4
Stats:     191 lines in 2 files changed: 189 ins; 0 del; 2 mod

8374382: (aio) AsynchronousFileChannel writes wrong content using heap ByteBuffer when position != 0

Reviewed-by: jpai
Backport-of: d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08

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

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

From alanb at openjdk.org  Mon Jan  5 12:58:48 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jan 2026 12:58:48 GMT
Subject: RFR: 8374441: FileSystemProvider.readAttributesIfExists should
 return null for ENOTDIR (unix)
In-Reply-To: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
Message-ID: <TTenBX7KZ4NNEmOISrWoI-cJ-dhiLzE7AkiCNBi11e0=.bb561e4b-2c6f-4459-b064-feb4de2785bd@github.com>

On Wed, 31 Dec 2025 21:14:29 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.

>  Title mismatch between PR and JBS.

Can you update the PR title to match the JBS issue?

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

> 100:             return attrs;
> 101:         else if (errno == UnixConstants.ENOENT ||
> 102:                  errno == UnixConstants.ENOTDIR)

I think this is okay. Can you update the end copyright from 2025 to 2026.

test/jdk/java/nio/file/Files/NotADirectory.java line 54:

> 52: 
> 53: import static org.junit.jupiter.api.Assertions.assertFalse;
> 54: import static org.junit.jupiter.api.Assertions.assertNull;

The tests in Files/* are meant to test the FIles API. I suppose it's okay to have it also test a related/underlying FileSystemProvider method but it will mean we need to update the test summary. Also need to add the JBS issue number to the `@bug` line.

test/jdk/java/nio/file/Files/NotADirectory.java line 151:

> 149:         assertNull(
> 150:             BOGUS.getFileSystem().provider().readAttributesIfExists(
> 151:                 BOGUS, BasicFileAttributes.class));

You can define a constant `static final FileSystemProvider PROVIDER = FileSystems.getDefault().provider()` and it will clean up these two tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/29013#issuecomment-3710305339
PR Review Comment: https://git.openjdk.org/jdk/pull/29013#discussion_r2661384778
PR Review Comment: https://git.openjdk.org/jdk/pull/29013#discussion_r2661387754
PR Review Comment: https://git.openjdk.org/jdk/pull/29013#discussion_r2661395319

From fmeum at openjdk.org  Mon Jan  5 16:18:38 2026
From: fmeum at openjdk.org (Fabian Meumertzheim)
Date: Mon, 5 Jan 2026 16:18:38 GMT
Subject: RFR: 8374441: (fs) FileSystemProvider.readAttributesIfExists
 throws "Not a directory" when element in path is not directory should return
 null for ENOTDIR (unix) [v2]
In-Reply-To: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
Message-ID: <S4O8END8ujRIFM_El-ChDt_mPSqMGnVTT7P4kAqOAeM=.1efb8b36-5a45-4ed5-b2fd-a9dbd37626a6@github.com>

> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.

Fabian Meumertzheim 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/29013/files
  - new: https://git.openjdk.org/jdk/pull/29013/files/d7377abf..91f4b3ac

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

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

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

From alanb at openjdk.org  Mon Jan  5 19:29:58 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jan 2026 19:29:58 GMT
Subject: RFR: 8374441: (fs) FileSystemProvider.readAttributesIfExists
 throws "Not a directory" when element in path is not directory should return
 null for ENOTDIR (unix) [v2]
In-Reply-To: <S4O8END8ujRIFM_El-ChDt_mPSqMGnVTT7P4kAqOAeM=.1efb8b36-5a45-4ed5-b2fd-a9dbd37626a6@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
 <S4O8END8ujRIFM_El-ChDt_mPSqMGnVTT7P4kAqOAeM=.1efb8b36-5a45-4ed5-b2fd-a9dbd37626a6@github.com>
Message-ID: <w4O3aCQl8g3oGI6CKlKeOXHW8BUjeSRw6zxeg6SLV2I=.6c0d021e-88ab-46e4-9cd3-a09931608b54@github.com>

On Mon, 5 Jan 2026 16:18:38 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

>> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

test/jdk/java/nio/file/Files/NotADirectory.java line 25:

> 23: 
> 24: /* @test
> 25:  * @bug 8356678 8374441

Thanks for the update, I think it looks okay. Can you update the end copyright date on the test? I don't have any other comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29013#discussion_r2662569066

From fmeum at openjdk.org  Mon Jan  5 20:16:22 2026
From: fmeum at openjdk.org (Fabian Meumertzheim)
Date: Mon, 5 Jan 2026 20:16:22 GMT
Subject: RFR: 8374441: (fs) FileSystemProvider.readAttributesIfExists
 throws "Not a directory" when element in path is not directory should return
 null for ENOTDIR (unix) [v3]
In-Reply-To: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
Message-ID: <zMg6hyoz4ClwTj4NQCU41iLNyPlJRC_TV9103Tx9nxs=.65ea1ce5-4292-4b8a-8580-f4252d34e3de@github.com>

> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.

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

  Update copyright range

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29013/files
  - new: https://git.openjdk.org/jdk/pull/29013/files/91f4b3ac..868e0f41

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

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

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

From bpb at openjdk.org  Mon Jan  5 20:49:23 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Jan 2026 20:49:23 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v19]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <kFhaxXu-xFdJ8f7vJ03SBs-AGWtje9R4exhzQlbED3U=.ff0ecdd9-8284-452f-a6a8-7102cc61fb62@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 9 more: https://git.openjdk.org/jdk/compare/27dbdec2...c7446357

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=18
  Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From alanb at openjdk.org  Tue Jan  6 06:47:42 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jan 2026 06:47:42 GMT
Subject: RFR: 8374441: (fs) FileSystemProvider.readAttributesIfExists
 throws "Not a directory" when element in path is not directory should return
 null for ENOTDIR (unix) [v3]
In-Reply-To: <zMg6hyoz4ClwTj4NQCU41iLNyPlJRC_TV9103Tx9nxs=.65ea1ce5-4292-4b8a-8580-f4252d34e3de@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
 <zMg6hyoz4ClwTj4NQCU41iLNyPlJRC_TV9103Tx9nxs=.65ea1ce5-4292-4b8a-8580-f4252d34e3de@github.com>
Message-ID: <S9eo_fG48HbkOy8IGhMSxZeDdvrC17S9NTlRXpJJ4mY=.21479e70-f9fc-4e09-8510-ae8082a9bb97@github.com>

On Mon, 5 Jan 2026 20:16:22 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

>> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright range

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29013#pullrequestreview-3629644573

From duke at openjdk.org  Tue Jan  6 06:56:23 2026
From: duke at openjdk.org (duke)
Date: Tue, 6 Jan 2026 06:56:23 GMT
Subject: RFR: 8374441: (fs) FileSystemProvider.readAttributesIfExists
 throws "Not a directory" when element in path is not directory should return
 null for ENOTDIR (unix) [v3]
In-Reply-To: <zMg6hyoz4ClwTj4NQCU41iLNyPlJRC_TV9103Tx9nxs=.65ea1ce5-4292-4b8a-8580-f4252d34e3de@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
 <zMg6hyoz4ClwTj4NQCU41iLNyPlJRC_TV9103Tx9nxs=.65ea1ce5-4292-4b8a-8580-f4252d34e3de@github.com>
Message-ID: <3f85In6PDZc2CLtZbrfp9C9kgMoDlEc5tN-rxcWv1XA=.c0595f4e-e7e6-4b3c-802a-557eb9580adf@github.com>

On Mon, 5 Jan 2026 20:16:22 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

>> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright range

@fmeum 
Your change (at version 868e0f41cbcd7ed0782c59c31b9bf3812e447d8b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29013#issuecomment-3713367953

From fmeum at openjdk.org  Tue Jan  6 08:12:13 2026
From: fmeum at openjdk.org (Fabian Meumertzheim)
Date: Tue, 6 Jan 2026 08:12:13 GMT
Subject: Integrated: 8374441: (fs) FileSystemProvider.readAttributesIfExists
 throws "Not a directory" when element in path is not directory should return
 null for ENOTDIR (unix)
In-Reply-To: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
References: <l1JtLqgvaRqV74tHmoiuKol_HZ1WYNIRxxJt2R9eyGE=.22fb53a7-2056-45ee-821f-e386b73b7052@github.com>
Message-ID: <y8X7RFBI7kFD8MoY8Qfzwl7MFG5i999HO3AUR40nODM=.917ef528-3936-4af8-bf36-356665e89944@github.com>

On Wed, 31 Dec 2025 21:14:29 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

> `FileSystemProvider.readAttributesIfExists` now returns `null` for a path with a true prefix that is not a directory rather than throwing `NotDirectoryException`.

This pull request has now been integrated.

Changeset: 2fbc4162
Author:    Fabian Meumertzheim <fmeum at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2fbc4162e808f14b6114499f49db3e6ef1590f24
Stats:     25 lines in 2 files changed: 20 ins; 0 del; 5 mod

8374441: (fs) FileSystemProvider.readAttributesIfExists throws "Not a directory" when element in path is not directory should return null for ENOTDIR (unix)

Reviewed-by: alanb

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

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

From vyazici at openjdk.org  Tue Jan  6 08:23:16 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:23:16 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
Message-ID: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>

Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210].

[JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

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

Commit messages:
 - Revert "8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics"

Changes: https://git.openjdk.org/jdk/pull/29055/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374523
  Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29055/head:pull/29055

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

From vyazici at openjdk.org  Tue Jan  6 08:23:16 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:23:16 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <zk3-XGiaG5jLISqVAtPgLgvcEOT9raXjQ_UefbivPCs=.b0496830-92a7-47b8-8696-60b22a7cb106@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Tier 1-3 are clear on c8acc80b8c6.

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

PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3713645184

From bpb at openjdk.org  Tue Jan  6 22:44:29 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 6 Jan 2026 22:44:29 GMT
Subject: RFR: 8374641: Remove java/nio/channels/AsyncCloseAndInterrupt.java
 from problem list
Message-ID: <oJjfLeY3J-798IC3bTHX5ejiGG1st_w9RbqmAWjMYBk=.676a2836-cf27-4bc0-a27a-aa5d0953805d@github.com>

Remove the test from the problem list as many repetitions of manual testing has not revealed any failures.

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

Commit messages:
 - 8374641: Remove java/nio/channels/AsyncCloseAndInterrupt.java from problem list

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

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

From iris at openjdk.org  Tue Jan  6 23:56:34 2026
From: iris at openjdk.org (Iris Clark)
Date: Tue, 6 Jan 2026 23:56:34 GMT
Subject: RFR: 8374641: Remove java/nio/channels/AsyncCloseAndInterrupt.java
 from problem list
In-Reply-To: <oJjfLeY3J-798IC3bTHX5ejiGG1st_w9RbqmAWjMYBk=.676a2836-cf27-4bc0-a27a-aa5d0953805d@github.com>
References: <oJjfLeY3J-798IC3bTHX5ejiGG1st_w9RbqmAWjMYBk=.676a2836-cf27-4bc0-a27a-aa5d0953805d@github.com>
Message-ID: <blnWhFhJh_227v7hsgP2jzWZiIoNrTKg_ZwARB_peP0=.9bf8cc8c-a15a-4aa0-a45e-fb277a44fc5d@github.com>

On Tue, 6 Jan 2026 22:28:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the test from the problem list as many repetitions of manual testing have not revealed any failures.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29074#pullrequestreview-3632877959

From lkorinth at openjdk.org  Wed Jan  7 12:35:42 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:35:42 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
> 
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>    
>    Reviewed-by: aboldtch
>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>    
>    Reviewed-by: serb, aivanov, dnguyen
>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

I will redo the merge, I have done something strange.

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595

From lkorinth at openjdk.org  Wed Jan  7 12:58:43 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:58:43 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:

 - Merge branch '8373253' into 8367993
 - Merge branch 'master' into _8373253
 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

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

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02
  Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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

From brian.burkhalter at oracle.com  Wed Jan  7 20:34:12 2026
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 7 Jan 2026 20:34:12 +0000
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
Message-ID: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>

Resuscitating  this discussion thread from last year ...

To summarize my rereading of the thread, there is good agreement that Path.{ends,starts}With(String) should be deprecated and replaced with something else, perhaps Path.{ends,starts}WithString(String). There was also a parallel suggestion that Path.{ends,starts}With(Path) be deprecated in favor of Path.{ends,starts}WithPath(Path). Thus:

* Path.{ends,starts}With(String) -> Path.{ends,starts}WithString(String)
* Path.{ends,starts}With(Path) -> Path.{ends,starts}WithPath(Path)

Among doubtlessly many others, one alternative is

1. Leave Path.{ends,starts}With(Path) unchanged
2. Deprecate Path.{ends,starts}With(String)
3. Add Path.pathString{ends,starts}With(String)

where "pathstring" in effect implies the value of Path.toString().

Comments?

Brian

On Nov 2, 2025, at 3:35?PM, David Alayachew <davidalayachew at gmail.com> wrote:

As for deprecations, I still think all 4 methods should be deprecated. This path variants are kind of ok, but the String variants are just too deceptively named.

I think Rob Spoor hit it on the head with this quote.

> Perhaps both can be added?
>
> Path.{start,end}sWithString would default to calling
> toString().{start,end}sWith(arg) and
> Path.{start,end}sWithPath would default to calling
> {start,end}sWith(arg). The latter could default to
> calling {start,end}sWith(getFileSystem().getPath(arg))
> but then custom implementations that do something else
> (in addition) may not work as expected.

Doing it this way, we can have (start|end)sWithPath() have both String and Path overloads with no ambiguity.

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

From brian.burkhalter at oracle.com  Wed Jan  7 21:44:51 2026
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 7 Jan 2026 21:44:51 +0000
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
Message-ID: <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>

In the list below I omitted adding Path.{ends,starts}WithString(String) which is different from item 3 in the list.

Brian

On Jan 7, 2026, at 12:34?PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

Among doubtlessly many others, one alternative is

1. Leave Path.{ends,starts}With(Path) unchanged
2. Deprecate Path.{ends,starts}With(String)
3. Add Path.pathString{ends,starts}With(String)

where "pathstring" in effect implies the value of Path.toString().

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

From brian.burkhalter at oracle.com  Thu Jan  8 00:25:30 2026
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 8 Jan 2026 00:25:30 +0000
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
Message-ID: <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>

Thanks for helping to continue to the discussion.

On Jan 7, 2026, at 4:13?PM, Olexandr Rotan <rotanolexandr842 at gmail.com> wrote:

I am not sure if thoughts similar to mine were already present in the thread, but I am not sure there is any particular value in adding any replacement methods for deprecated ones.

Nor am I.

To me it seems like path.toString.{starts,ends}With provides endlessly more clarity on what is going on, besides maybe  pathString{ends,starts}With, but this name seems clumsy, in some way resembling some denormalized column name in db in a way that it traverses multiple mental indirections to explain clearly enough what it does

Indeed the name is clumsy.

So, as I think, unless there is a substantial optimization to offer from merging this two operations, i would prefer just suggesting to use toString().{starts,ends}With directly

Maybe that is the way to go: just deprecating Path.{ends,starts}With(String) and nothing else.

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

From john.r.rose at oracle.com  Thu Jan  8 00:30:06 2026
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 07 Jan 2026 16:30:06 -0800
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
Message-ID: <5D44395C-D731-4F19-88AC-BB82AA1D771E@oracle.com>

On 7 Jan 2026, at 12:34, Brian Burkhalter wrote:

> Resuscitating  this discussion thread from last year ...
>
> To summarize my rereading of the thread, there is good agreement that Path.{ends,starts}With(String) should be deprecated and replaced with something else, perhaps Path.{ends,starts}WithString(String). There was also a parallel suggestion that Path.{ends,starts}With(Path) be deprecated in favor of Path.{ends,starts}WithPath(Path). Thus:
>
> * Path.{ends,starts}With(String) -> Path.{ends,starts}WithString(String)
> * Path.{ends,starts}With(Path) -> Path.{ends,starts}WithPath(Path)
>
> Among doubtlessly many others, one alternative is
>
> 1. Leave Path.{ends,starts}With(Path) unchanged
> 2. Deprecate Path.{ends,starts}With(String)
> 3. Add Path.pathString{ends,starts}With(String)
>
> where "pathstring" in effect implies the value of Path.toString().
>
> Comments?

$0.02 ? I like it.  I think David and Pavel have pointed out
a legitimately significant "sharp edge" in the API, where it is
too easy to read /foo.startsWith("bar")/ and read that as a string
operation.  But it isn?t.

(Any other string-like methods out there?  Any other /foo/ that
responds to /.startsWith("bar")/ but does something different
from /foo.toString()/?)

Olexandr?s observation about factoring the string ops via
Path::toString is also spot-on.  However, it?s not a cure-all,
especially given the "false friend" methods already in Path.

I would suggest that, if we add new "true friend" methods in
Path, that they should say something like "this is the same as
calling /toString().startWith(x)/ but may be more efficient".

Javadoc does (at least) two useful things at the same time:
It A. makes it easier to discover useful API points, and B. teaches
you how to use both those API points and related ones.  The very
presence of Path::endsWithString (or whatever) makes the
useful API point (A) discoverable, but then it can also suggest,
(B) "hey, did you consider calling toString first?".

? John

From john.r.rose at oracle.com  Thu Jan  8 00:32:58 2026
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 07 Jan 2026 16:32:58 -0800
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
Message-ID: <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>

On 7 Jan 2026, at 16:25, Brian Burkhalter wrote:

> ?So, as I think, unless there is a substantial optimization to offer from merging this two operations, i would prefer just suggesting to use toString().{starts,ends}With directly
>
> Maybe that is the way to go: just deprecating Path.{ends,starts}With(String) and nothing else.

$0.01 more ? I?m OK with that, as long as the javadoc teaches
the toString technique in some discoverable manner.  And not just
via the deprecated methods??

From stuart.marks at oracle.com  Thu Jan  8 00:36:04 2026
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 7 Jan 2026 16:36:04 -0800
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
Message-ID: <dcb074d8-8be3-423c-bc2a-8dae9f37c4d1@oracle.com>


On 1/7/26 12:34 PM, Brian Burkhalter wrote:
> Resuscitating ?this discussion thread from last year ...
>
> To summarize my rereading of the thread, there is good agreement that 
> Path.{ends,starts}With(String) should be deprecated and replaced with something 
> else, perhaps Path.{ends,starts}WithString(String). There was also a parallel 
> suggestion that Path.{ends,starts}With(Path) be deprecated in favor of 
> Path.{ends,starts}WithPath(Path). Thus:
>
> * Path.{ends,starts}With(String) -> Path.{ends,starts}WithString(String)
> * Path.{ends,starts}With(Path) -> Path.{ends,starts}WithPath(Path)

My experience is that deprecation for the purposes of renaming doesn't work very 
well. I don't think we're intending to remove the old APIs, so they'd remain, so 
"renaming" would merely be the addition of new APIs with similar names. This would 
just make things more confusing.

The main problem is that Path.{ends,starts}With(String) is confusing and misleading, 
so let's focus on that.

> Among doubtlessly many others, one alternative is
>
> 1. Leave Path.{ends,starts}With(Path) unchanged

This makes sense. I haven't seen any evidence that this is a problem if one is 
already working in the Path domain.

> 2. Deprecate Path.{ends,starts}With(String)

This is the confusing one, so yes, deprecate this (not for removal). It's an open 
question regarding what the deprecation text should recommend be used instead. 
Perhaps some of the discussion below will resolve this.

> 3. Add Path.pathString{ends,starts}With(String)
>
> where "pathstring" in effect implies the value of Path.toString().

Before we start adding new APIs, I think we should consider which use cases we think 
we want to support. The methods take a string argument, and the two cases are 
whether the operation is performed on Paths and Path segments or whether the 
operation is performed in terms of Strings.

For brevity I'll just use "EW" to represent the "endsWith" operation in either 
domain, but the analysis applies equally to the "startsWith" operation.

Suppose we start off with

var path = Path.of("/one/two/three");

The cases are:

a) Path domain. The code path.EW(string) is equivalent to

path.endsWith(path.getFileSystem().getPath(string))
 ??? // note, this is Path.endsWith(Path)

and thus we have

 ??? path.EW("/two/three") ==> false
 ??? path.EW("two/three") ==> true

b) String domain. The code path.EW(string) is equivalent to

 ??? path.toString().endsWith(string)
 ??? // note, this is String.endsWith(String)

and thus we have

 ??? path.EW("/two/three") ==> true
 ??? path.EW("two/three") ==> true

=====

I'm not convinced we need any new APIs at all. It seems likely that many people want 
to perform the string-based endsWith() operation, in which case maybe it's best to 
be explicit and convert the path to a string using toString() before doing that. 
Adding a deprecation for Path.endsWith(String) should warn people not to use this 
method for the string-domain case.

If you want to perform this operation in the Path domain, maybe it's best to be 
explicit about it. If you're writing library code that wants to be very general, 
then you probably have the relevant FileSystem in a local variable already, and you 
might construct Path objects explicitly before invoking the endsWith(Path) 
operation. Using string literals directly, and having them implicitly be converted 
to Path objects, seems like it easily leads to subtle problems (such as the 
difference in behavior between my "/two/three" and "two/three" examples above.) So, 
maybe being explicit is better, even if it is more verbose and less convenient.

If you're writing an application that uses the default FileSystem everywhere, and 
you really want to perform a Path-based operation, you can just slap Path.of() 
around your string literal and move on. I don't think we need another method to 
handle this case.

So, maybe do (1) and (2) but omit (3). This boils down to just deprecating 
endsWith(String) and startsWith(String).

s'marks

>
> Comments?
>
> Brian
>
>> On Nov 2, 2025, at 3:35?PM, David Alayachew <davidalayachew at gmail.com> wrote:
>>
>> As for deprecations, I still think all 4 methods should be deprecated. This path 
>> variants are kind of ok, but the String variants are just too deceptively named.
>>
>> I think Rob Spoor hit it on the head with this quote.
>>
>> > Perhaps both can be added?
>> >
>> > Path.{start,end}sWithString would default to calling
>> > toString().{start,end}sWith(arg) and
>> > Path.{start,end}sWithPath would default to calling
>> > {start,end}sWith(arg). The latter could default to
>> > calling {start,end}sWith(getFileSystem().getPath(arg))
>> > but then custom implementations that do something else
>> > (in addition) may not work as expected.
>>
>> Doing it this way, we can have (start|end)sWithPath() have both String and Path 
>> overloads with no ambiguity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260107/64c62b6e/attachment-0001.htm>

From brian.burkhalter at oracle.com  Thu Jan  8 01:02:30 2026
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 8 Jan 2026 01:02:30 +0000
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
Message-ID: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>

Thanks for the useful comments.

On Jan 7, 2026, at 4:32?PM, John Rose <john.r.rose at oracle.com> wrote:

Maybe that is the way to go: just deprecating Path.{ends,starts}With(String) and nothing else.

$0.01 more ? I?m OK with that, as long as the javadoc teaches
the toString technique in some discoverable manner.  And not just
via the deprecated methods??

On Jan 7, 2026, at 4:36?PM, Stuart Marks <stuart.marks at oracle.com> wrote:

So, maybe do (1) and (2) but omit (3). This boils down to just deprecating endsWith(String) and startsWith(String).

We have had a bit of a race condition in this discussion, but at least there appears to be some agreement that deprecation alone (with some javadoc enhancement) is a good way to go.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260108/d09c8088/attachment.htm>

From alan.bateman at oracle.com  Thu Jan  8 09:39:31 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Thu, 8 Jan 2026 09:39:31 +0000
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
Message-ID: <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>



On 08/01/2026 01:02, Brian Burkhalter wrote:
>
> We have had a bit of a race condition in this discussion, but at least 
> there appears to be some agreement that deprecation alone (with some 
> javadoc enhancement) is a good way to go.

It would be also be good to try again to get a handle on the use-cases 
around the convention that we know as the "file extension". We've had 
several failed attempts on this but I think you make good progress on 
defining it at the last iteration. That is, I assume some temptation to 
use endsWith(String) is just wanting to test if the string 
representation has an interesting suffix.

-Alan


From vyazici at openjdk.org  Thu Jan  8 09:51:51 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 Jan 2026 09:51:51 GMT
Subject: [jdk26] RFR: 8374700: [BACKOUT] Move input validation checks to Java
 for java.lang.StringCoding intrinsics
Message-ID: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>

Backport of [JDK-8374210] integrated in 7e18de13 by #29055.

[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

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

Commit messages:
 - Backport 7e18de137c3b5f08a479af2b64eb22923261900b

Changes: https://git.openjdk.org/jdk/pull/29112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374700
  Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29112/head:pull/29112

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

From anthonyv.be at outlook.com  Thu Jan  8 10:49:32 2026
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Thu, 8 Jan 2026 11:49:32 +0100
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
Message-ID: <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>

On 1/8/2026 10:39 AM, Alan Bateman wrote:
> On 08/01/2026 01:02, Brian Burkhalter wrote:
>> We have had a bit of a race condition in this discussion, but at 
>> least there appears to be some agreement that deprecation alone (with 
>> some javadoc enhancement) is a good way to go.
> It would be also be good to try again to get a handle on the use-cases 
> around the convention that we know as the "file extension". We've had 
> several failed attempts on this but I think you make good progress on 
> defining it at the last iteration. That is, I assume some temptation 
> to use endsWith(String) is just wanting to test if the string 
> representation has an interesting suffix.
>
> -Alan 
Alan is spot on here, and I'm wholeheartedly in favor of leaving the API 
untouched.

What I believe is needed, is simply to:
* add a method to get the file extension from a Path (people want to get 
the file extension from a Path, notice there's no method to do so, 
notice `endsWith(String)`, use that, eventually find out it doesn't work 
as they expected, and then blame `endsWith(String)`)
* point out that the current APIs actually are intuitive (when a method 
is overloaded, I intuitively expect all overloads to behave in the same 
manner, except for a trivial conversion of their arguments to some 
canonical form. This is exactly the case here)
* remind people to read the Javadoc (the Javadoc of these methods is 
crystal clear on their behavior)

The existing methods are useful (fwiw, in my codebases all uses of 
`Path::endsWith` invoke the `String` overload) and have many uses in 
existing codebases (as they've existed for nearly 15 years). And again, 
the actual issue is people expecting methods to behave as needed in the 
context of their actual use case (here, in 99% of the cases: testing the 
file extension), without verifying their expectations by reading the 
Javadoc.

Deprecating these methods is also a sure-fire way to have people 
introduce subtle bugs in their codebases, as they'd likely "fix" the 
deprecations by replacing `path.endsWith("other")` with 
`path.endsWith(Path.of("other"))`.

Adding `Path.pathString{ends,starts}With(String)` would be a mistake, I 
believe. One of the things that makes `Path` such a fine API, is that it 
cleanly abstracts the OS-specific file separator. These methods would 
break that abstraction and you'd end up with things like 
`Path.of("foo\bar").pathStringStartsWith("foo/bar")` and either way 
you'd have people complaining that its behavior is unintuitive (i.e., 
some people would expect this to return `true`, others `false`).

Anthony

From bpb at openjdk.org  Thu Jan  8 16:31:11 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Jan 2026 16:31:11 GMT
Subject: RFR: 8374641: Remove java/nio/channels/AsyncCloseAndInterrupt.java
 from problem list
In-Reply-To: <blnWhFhJh_227v7hsgP2jzWZiIoNrTKg_ZwARB_peP0=.9bf8cc8c-a15a-4aa0-a45e-fb277a44fc5d@github.com>
References: <oJjfLeY3J-798IC3bTHX5ejiGG1st_w9RbqmAWjMYBk=.676a2836-cf27-4bc0-a27a-aa5d0953805d@github.com>
 <blnWhFhJh_227v7hsgP2jzWZiIoNrTKg_ZwARB_peP0=.9bf8cc8c-a15a-4aa0-a45e-fb277a44fc5d@github.com>
Message-ID: <bKGlw3sHAcv1yalefS7GAo-LYFJct59Jr5xtZBLzV0M=.0e85026d-e8d0-43d4-ae0a-88fdfbb771f0@github.com>

On Tue, 6 Jan 2026 23:53:14 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Remove the test from the problem list as many repetitions of manual testing have not revealed any failures.
>
> Marked as reviewed by iris (Reviewer).

@irisclark Thanks for the prompt review.

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

PR Comment: https://git.openjdk.org/jdk/pull/29074#issuecomment-3724656956

From bpb at openjdk.org  Thu Jan  8 16:31:12 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Jan 2026 16:31:12 GMT
Subject: Integrated: 8374641: Remove
 java/nio/channels/AsyncCloseAndInterrupt.java from problem list
In-Reply-To: <oJjfLeY3J-798IC3bTHX5ejiGG1st_w9RbqmAWjMYBk=.676a2836-cf27-4bc0-a27a-aa5d0953805d@github.com>
References: <oJjfLeY3J-798IC3bTHX5ejiGG1st_w9RbqmAWjMYBk=.676a2836-cf27-4bc0-a27a-aa5d0953805d@github.com>
Message-ID: <bl7YRmPkNUXwFxCjVjh4aOnLa9RhFjiWlg0fF9l-3s0=.ffe83acb-0be6-4ae9-b9cd-d97e20eb919f@github.com>

On Tue, 6 Jan 2026 22:28:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the test from the problem list as many repetitions of manual testing have not revealed any failures.

This pull request has now been integrated.

Changeset: ec657349
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec657349ff654dcb41b9f17178aeea638329101e
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8374641: Remove java/nio/channels/AsyncCloseAndInterrupt.java from problem list

Reviewed-by: iris

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

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

From sjohanss at openjdk.org  Fri Jan  9 08:47:01 2026
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 9 Jan 2026 08:47:01 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
Message-ID: <CNxPXaG8qXqVrPo5NsiiGa6M6r3hPE9UcLKaDYkr5is=.26f84708-d442-45b0-b787-fda252292bee@github.com>

On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:
> 
>  - Merge branch '8373253' into 8367993
>  - Merge branch 'master' into _8373253
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

Thanks for looking into this Leo. 

Overall I think it looks good, just some small questions and suggestions.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637:

> 1635: 
> 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const {
> 1637:   assert(_cm != nullptr, "thread must exist in order to check if mark is terminating");

I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427:

> 2425:   if (_cm->is_fully_initialized()) {
> 2426:     tc->do_thread(_cm->cm_thread());
> 2427:   }

Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()`

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549:

> 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) {
> 2548:   assert(!_cm->in_progress(), "Can not start concurrent operation while in progress");
> 2549:   assert(_cm->is_fully_initialized(), "sanity");

Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert.

src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46:

> 44:     return false;
> 45:   }
> 46: 

Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right?

src/hotspot/share/gc/g1/g1Policy.cpp line 744:

> 742:   if (!_g1h->concurrent_mark()->is_fully_initialized()) {
> 743:     return false;
> 744:   }

Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127:

> 1125: 
> 1126: void G1YoungCollector::collect() {
> 1127:   _g1h->_cm->fully_initialize();

I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)`

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630

From stefank at openjdk.org  Fri Jan  9 12:09:22 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 12:09:22 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
 <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
Message-ID: <aSHHOBAAdNFMkL3dy7qiMutT8mTtX0R5pLQU6kB4Diw=.38610782-7ad7-44f6-9d44-4cf8164b9562@github.com>

On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into _8367993
>>  - 8366058: Outdated comment in WinCAPISeedGenerator
>>    
>>    Reviewed-by: mullan
>>  - 8357258: x86: Improve receiver type profiling reliability
>>    
>>    Reviewed-by: kvn, vlivanov
>>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>>    
>>    Reviewed-by: lucy, jpai
>>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>>    
>>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>>    
>>    Reviewed-by: alanb, dholmes
>>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>>    
>>    Reviewed-by: kbarrett
>>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>>    
>>    Reviewed-by: djelinski, mpowers, ascarpino
>>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>>    
>>    Reviewed-by: aboldtch
>>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>>    
>>    Reviewed-by: serb, aivanov, dnguyen
>>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767
>
> I will redo the merge, I have done something strange.

@lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels?

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315

From brian.burkhalter at oracle.com  Sat Jan 10 03:05:56 2026
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Sat, 10 Jan 2026 03:05:56 +0000
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
 <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
Message-ID: <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com>

Thanks for the corroboration.

On Jan 8, 2026, at 1:50?PM, David Alayachew <davidalayachew at gmail.com> wrote:

Thanks for reviving this.

I am perfectly happy with the idea of deprecating the Path.{start,ends}With(String), and then only add the file extension method. Originally, I didn't know that new method was on the table, so I suggested a rename. But the file extension api feels like the superior solution.

10 times out of 10, if I am calling endsWith, the only time I am not looking for "whole" path elements is when I am looking for a file extension. In every other instance, the api does exactly what I expect and want. And plus, something like looking for a file extension is better off being explicit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260110/a347cf89/attachment.htm>

From anthonyv.be at outlook.com  Sun Jan 11 19:06:22 2026
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Sun, 11 Jan 2026 20:06:22 +0100
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAA9v-_PUvm+XjATAkTz1QJyv6M2tnYmpdrORMgrxUKZLJ2LCuw@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAChcVu=+rxLyTgftP12WALBZA6dnipLET0HCUFDFK9Y0RqBWXQ@mail.gmail.com>
 <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com>
 <CAChcVunpqAzNvBuajzpGb_6Xs1h8bzj+mYKC-ZRsh_SXjzjivQ@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
 <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
 <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com>
 <CAA9v-_PUvm+XjATAkTz1QJyv6M2tnYmpdrORMgrxUKZLJ2LCuw@mail.gmail.com>
Message-ID: <AM7PPF6DBABEF0E7C27EF7A2858B9DBBE2CE880A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>

I dissent. (Apparently my previous message wasn't clear.)

The right order of things is to first introduce a file extension API. 
Then see if there's still complaints about `Path::endsWith(String)`. And 
only then, if there are, consider taking action.

In my previous message I've already explained how these methods add 
real, tangible value and actually are intuitive.
(Again, ask developers to guess how `A::foo(B)` behaves, given that both 
`A::foo(A)` and `B::foo(B)` exist, and a large majority of them will 
intuitively guess it converts its `b` argument to an instance of `A` and 
passes it on to `A::foo(A)`. And their intuition would be correct in the 
case of `Path::endsWith(String)`. That being said, I'll be the first to 
admit that I've also made the mistake of attempting to use 
`Path::endsWith(String)` to test the file extension.)

In hindsight, maybe `endsWithNames(String)` would've been a better 
choice, but hindsight is 20/20.

Deprecating these methods now is premature. And deprecating them without 
replacement methods would result in way more complaints than there have 
ever been about `endsWith(String)`.

Anthony

On 1/11/2026 12:19 AM, David Alayachew wrote:
> Of course.
>
> I see lots of approvals and not really any dissenters. Are we waiting 
> for more responses? Or is there anything we can do to kick start this?
>
> On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter 
> <brian.burkhalter at oracle.com> wrote:
>
>     Thanks for the corroboration.
>
>>     On Jan 8, 2026, at 1:50?PM, David Alayachew
>>     <davidalayachew at gmail.com> wrote:
>>
>>     Thanks for reviving this.
>>
>>     I am perfectly happy with the idea of deprecating the
>>     Path.{start,ends}With(String), and then only add the file
>>     extension method. Originally, I didn't know that new method was
>>     on the table, so I suggested a rename. But the file extension api
>>     feels like the superior solution.
>>
>>     10 times out of 10, if I am calling endsWith, the only time I am
>>     not looking for "whole" path elements is when I am looking for a
>>     file extension. In every other instance, the api does exactly
>>     what I expect and want. And plus, something like looking for a
>>     file extension is better off being explicit.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260111/273471e4/attachment-0001.htm>

From alanb at openjdk.org  Mon Jan 12 12:56:31 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Jan 2026 12:56:31 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move
In-Reply-To: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
Message-ID: <r6H7rbpGvgtDPbbMS31_-TXWrYuOUI_Wm2gDVT1gAlg=.cdb88ed4-5079-440e-92db-4efa4c3e9e30@github.com>

On Tue, 9 Sep 2025 23:04:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `java.nio.file.SecureDirectoryStream.move` so that, instead of throwing a `NullPointerException` if the `targetdir` parameter is `null`, it considers a non-absolute path passed via `targetpath` as being relative to the current working directory.

src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 205:

> 203:      *          the name of the file to move
> 204:      * @param   targetdir
> 205:      *          the destination directory

The proposed spec looks okay I think you can add "can be null" to the `@param description to make it clear in the parameter description too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2682155386

From stuart.marks at oracle.com  Mon Jan 12 19:36:42 2026
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 12 Jan 2026 11:36:42 -0800
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <CAA9v-_N24Mv5+JabZQHjuyMZVBCHE4c-_y2ByQ6omxQwyYbD3A@mail.gmail.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
 <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
 <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com>
 <CAA9v-_PUvm+XjATAkTz1QJyv6M2tnYmpdrORMgrxUKZLJ2LCuw@mail.gmail.com>
 <AM7PPF6DBABEF0E7C27EF7A2858B9DBBE2CE880A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_N24Mv5+JabZQHjuyMZVBCHE4c-_y2ByQ6omxQwyYbD3A@mail.gmail.com>
Message-ID: <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com>

Let's not tie these two issues together.

The discussion clearly shows that the startsWith/endsWith(String) APIs are a trap 
that several people have fallen into. On that basis it should be deprecated. 
(Ordinarily, so as to emit a warning, and not for removal, so there won't be any 
compatibility issue.)

There is also no requirement that a new API be introduced to replace any deprecated 
API. As the earlier discussion in the thread shows, both the path-based and the 
string-based use cases can be written using existing APIs, somewhat less 
conveniently and more verbosely; but these constructs are much more explicit and so 
are preferable to the APIs to be deprecated. The deprecation text should steer 
people toward the preferred constructs.

It would indeed be nice to have a file extension API, but this has been discussed 
several times and has run aground each time for a variety of reasons. Tying these 
together will hold up the deprecation for no good reason.

Let's proceed with just the deprecation first and work on the file extension API 
separately.

s'marks

On 1/11/26 12:45 PM, David Alayachew wrote:
> Thanks for the response Anthony. Messages have been arriving out-of-order for me, 
> so I didn't see yours at the time of me writing that message.
>
> I think introducing the file extension API first, then gauging the need for a 
> deprecation before doing it is fine. Sounds like then that we are universally 
> agreed on the first step being to add the file extension API, yes?
>
> On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe <anthonyv.be at outlook.com> 
> wrote:
>
>     I dissent. (Apparently my previous message wasn't clear.)
>
>     The right order of things is to first introduce a file extension API. Then see
>     if there's still complaints about `Path::endsWith(String)`. And only then, if
>     there are, consider taking action.
>
>     In my previous message I've already explained how these methods add real,
>     tangible value and actually are intuitive.
>     (Again, ask developers to guess how `A::foo(B)` behaves, given that both
>     `A::foo(A)` and `B::foo(B)` exist, and a large majority of them will
>     intuitively guess it converts its `b` argument to an instance of `A` and
>     passes it on to `A::foo(A)`. And their intuition would be correct in the case
>     of `Path::endsWith(String)`. That being said, I'll be the first to admit that
>     I've also made the mistake of attempting to use `Path::endsWith(String)` to
>     test the file extension.)
>
>     In hindsight, maybe `endsWithNames(String)` would've been a better choice, but
>     hindsight is 20/20.
>
>     Deprecating these methods now is premature. And deprecating them without
>     replacement methods would result in way more complaints than there have ever
>     been about `endsWith(String)`.
>
>     Anthony
>
>     On 1/11/2026 12:19 AM, David Alayachew wrote:
>>     Of course.
>>
>>     I see lots of approvals and not really any dissenters. Are we waiting for
>>     more responses? Or is there anything we can do to kick start this?
>>
>>     On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter <brian.burkhalter at oracle.com>
>>     wrote:
>>
>>         Thanks for the corroboration.
>>
>>>         On Jan 8, 2026, at 1:50?PM, David Alayachew <davidalayachew at gmail.com>
>>>         wrote:
>>>
>>>         Thanks for reviving this.
>>>
>>>         I am perfectly happy with the idea of deprecating the
>>>         Path.{start,ends}With(String), and then only add the file extension
>>>         method. Originally, I didn't know that new method was on the table, so I
>>>         suggested a rename. But the file extension api feels like the superior
>>>         solution.
>>>
>>>         10 times out of 10, if I am calling endsWith, the only time I am not
>>>         looking for "whole" path elements is when I am looking for a file
>>>         extension. In every other instance, the api does exactly what I expect
>>>         and want. And plus, something like looking for a file extension is
>>>         better off being explicit.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260112/51633f5a/attachment-0001.htm>

From bpb at openjdk.org  Mon Jan 12 20:57:27 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 Jan 2026 20:57:27 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v2]
In-Reply-To: <r6H7rbpGvgtDPbbMS31_-TXWrYuOUI_Wm2gDVT1gAlg=.cdb88ed4-5079-440e-92db-4efa4c3e9e30@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
 <r6H7rbpGvgtDPbbMS31_-TXWrYuOUI_Wm2gDVT1gAlg=.cdb88ed4-5079-440e-92db-4efa4c3e9e30@github.com>
Message-ID: <OQ4osE9AU7pw-g_vptAIPw9CBcb52Y6t2lnUuhhIqu4=.ff8667dd-9356-4e75-94d1-ab037e2f0b2f@github.com>

On Mon, 12 Jan 2026 12:53:12 GMT, Alan Bateman <alanb 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 four additional commits since the last revision:
>> 
>>  - 8367284: Update targetdir param verbiage to allow null
>>  - Merge
>>  - 8367284: Update test after all
>>  - 8367284: (fs) Support current working directory target in SecureDirectoryStream.move
>
> src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 205:
> 
>> 203:      *          the name of the file to move
>> 204:      * @param   targetdir
>> 205:      *          the destination directory
> 
> The proposed spec looks okay I think you can add "can be null" to the `@param description to make it clear in the parameter description too.

Updated in 7c21d87.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2683875175

From bpb at openjdk.org  Mon Jan 12 20:57:24 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 Jan 2026 20:57:24 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v2]
In-Reply-To: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
Message-ID: <OCOuv6f-NDE3tsPMkJjuc2-HoXgHko4iX5xT80wUgzI=.327586d1-20c4-4b14-a9f8-765302ed46f4@github.com>

> Change `java.nio.file.SecureDirectoryStream.move` so that, instead of throwing a `NullPointerException` if the `targetdir` parameter is `null`, it considers a non-absolute path passed via `targetpath` as being relative to the current working directory.

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

 - 8367284: Update targetdir param verbiage to allow null
 - Merge
 - 8367284: Update test after all
 - 8367284: (fs) Support current working directory target in SecureDirectoryStream.move

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27178/files
  - new: https://git.openjdk.org/jdk/pull/27178/files/5eeb5873..7c21d87e

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

  Stats: 639253 lines in 8209 files changed: 433573 ins; 122979 del; 82701 mod
  Patch: https://git.openjdk.org/jdk/pull/27178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27178/head:pull/27178

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

From alanb at openjdk.org  Tue Jan 13 06:44:45 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Jan 2026 06:44:45 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v2]
In-Reply-To: <OCOuv6f-NDE3tsPMkJjuc2-HoXgHko4iX5xT80wUgzI=.327586d1-20c4-4b14-a9f8-765302ed46f4@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
 <OCOuv6f-NDE3tsPMkJjuc2-HoXgHko4iX5xT80wUgzI=.327586d1-20c4-4b14-a9f8-765302ed46f4@github.com>
Message-ID: <QbEczWgFKooAnIj9nSy_bAJ0KjDPH_ZSW-bveVILcxo=.fab523d6-cf2a-4a18-9119-fe6acbda3d7b@github.com>

On Mon, 12 Jan 2026 20:57:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `java.nio.file.SecureDirectoryStream.move` so that, instead of throwing a `NullPointerException` if the `targetdir` parameter is `null`, it considers a non-absolute path passed via `targetpath` as being relative to the current working directory.
>
> 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 four additional commits since the last revision:
> 
>  - 8367284: Update targetdir param verbiage to allow null
>  - Merge
>  - 8367284: Update test after all
>  - 8367284: (fs) Support current working directory target in SecureDirectoryStream.move

Update looks okay, will you create the CSR for this?

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 305:

> 303:             if (ds instanceof SecureDirectoryStream<Path> sds) {
> 304:                 sds.move(file, null, file);
> 305:                 if (!Files.exists(result))

I think drop the Files.exist check here, the Files.readString will give a better exception if the readString fails.

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 312:

> 310:                 throw new RuntimeException("Not a SecureDirectoryStream");
> 311:             }
> 312:             System.out.println("Success: \"" + TEXT + "\"");

Just FYI that none of the tests in this method print trace messages so this "Success: ..." will look a bit odd in the .jtr output, esp. with tests that are added after this one. Maybe a left over? Maybe future work to move this to a junit test.

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

PR Comment: https://git.openjdk.org/jdk/pull/27178#issuecomment-3742270016
PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2685051747
PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2685050138

From bpb at openjdk.org  Tue Jan 13 18:11:57 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Jan 2026 18:11:57 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v2]
In-Reply-To: <QbEczWgFKooAnIj9nSy_bAJ0KjDPH_ZSW-bveVILcxo=.fab523d6-cf2a-4a18-9119-fe6acbda3d7b@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
 <OCOuv6f-NDE3tsPMkJjuc2-HoXgHko4iX5xT80wUgzI=.327586d1-20c4-4b14-a9f8-765302ed46f4@github.com>
 <QbEczWgFKooAnIj9nSy_bAJ0KjDPH_ZSW-bveVILcxo=.fab523d6-cf2a-4a18-9119-fe6acbda3d7b@github.com>
Message-ID: <0Ed_q6GbBFLOuUD4mBheZlwITbvSzSvPsk7J51h6ABg=.e4f16f09-fbb5-4291-a010-683681602ddd@github.com>

On Tue, 13 Jan 2026 06:41:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Update looks okay, will you create the CSR for this?

Yes.

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

PR Comment: https://git.openjdk.org/jdk/pull/27178#issuecomment-3745695600

From bpb at openjdk.org  Tue Jan 13 19:05:45 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Jan 2026 19:05:45 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v3]
In-Reply-To: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
Message-ID: <5vsDiYvGWfGQkFo7cM8e23xeHZCgz-j1e6pvCg2nshs=.f37ce438-55cd-42ba-a394-d1905abd2bbe@github.com>

> Change `java.nio.file.SecureDirectoryStream.move` so that, instead of throwing a `NullPointerException` if the `targetdir` parameter is `null`, it considers a non-absolute path passed via `targetpath` as being relative to the current working directory.

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

  8367284: Address comments about test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27178/files
  - new: https://git.openjdk.org/jdk/pull/27178/files/7c21d87e..8b9a5df2

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

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

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

From bpb at openjdk.org  Tue Jan 13 19:05:48 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Jan 2026 19:05:48 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v2]
In-Reply-To: <QbEczWgFKooAnIj9nSy_bAJ0KjDPH_ZSW-bveVILcxo=.fab523d6-cf2a-4a18-9119-fe6acbda3d7b@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
 <OCOuv6f-NDE3tsPMkJjuc2-HoXgHko4iX5xT80wUgzI=.327586d1-20c4-4b14-a9f8-765302ed46f4@github.com>
 <QbEczWgFKooAnIj9nSy_bAJ0KjDPH_ZSW-bveVILcxo=.fab523d6-cf2a-4a18-9119-fe6acbda3d7b@github.com>
Message-ID: <asnIlQ441bH-Puf1zn9BwtJh6NJzi0CaqSzqprYyRiI=.f32e0c3a-801c-461c-922a-0c7aa6698889@github.com>

On Tue, 13 Jan 2026 06:41:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> drop the Files.exist check here

Dropped in commit 8b9a5df.

> "Success: ..." will look a bit odd in the .jtr output

Removed in commit 8b9a5df.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2687701794
PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2687699827

From bpb at openjdk.org  Tue Jan 13 19:05:49 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Jan 2026 19:05:49 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v2]
In-Reply-To: <asnIlQ441bH-Puf1zn9BwtJh6NJzi0CaqSzqprYyRiI=.f32e0c3a-801c-461c-922a-0c7aa6698889@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
 <OCOuv6f-NDE3tsPMkJjuc2-HoXgHko4iX5xT80wUgzI=.327586d1-20c4-4b14-a9f8-765302ed46f4@github.com>
 <QbEczWgFKooAnIj9nSy_bAJ0KjDPH_ZSW-bveVILcxo=.fab523d6-cf2a-4a18-9119-fe6acbda3d7b@github.com>
 <asnIlQ441bH-Puf1zn9BwtJh6NJzi0CaqSzqprYyRiI=.f32e0c3a-801c-461c-922a-0c7aa6698889@github.com>
Message-ID: <Dr0tOsb5MkzaeGw8wv-UxDlkd1UbeNaz7KAhIXDgfsk=.d09c40fa-ae68-4a25-9309-7714c6ccf01b@github.com>

On Tue, 13 Jan 2026 19:01:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 312:
>> 
>>> 310:                 throw new RuntimeException("Not a SecureDirectoryStream");
>>> 311:             }
>>> 312:             System.out.println("Success: \"" + TEXT + "\"");
>> 
>> Just FYI that none of the tests in this method print trace messages so this "Success: ..." will look a bit odd in the .jtr output, esp. with tests that are added after this one. Maybe a left over? Maybe future work to move this to a junit test.
>
>> "Success: ..." will look a bit odd in the .jtr output
> 
> Removed in commit 8b9a5df.

> Maybe future work to move this to a junit test.

Maybe in this PR once it is otherwise quiescent, otherwise in future work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27178#discussion_r2687706461

From anthonyv.be at outlook.com  Tue Jan 13 20:13:40 2026
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Tue, 13 Jan 2026 21:13:40 +0100
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAA9v-_MkxQ3M38dA=uphnivEtC+V2rT8Vx6h1tcFbsyp-y4eEw@mail.gmail.com>
 <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
 <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
 <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com>
 <CAA9v-_PUvm+XjATAkTz1QJyv6M2tnYmpdrORMgrxUKZLJ2LCuw@mail.gmail.com>
 <AM7PPF6DBABEF0E7C27EF7A2858B9DBBE2CE880A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_N24Mv5+JabZQHjuyMZVBCHE4c-_y2ByQ6omxQwyYbD3A@mail.gmail.com>
 <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com>
Message-ID: <AM7PPF6DBABEF0E21BF3DDA6EDCA6B5E61FE88EA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>

There are 3 questions:

(1) should we deprecate `Path::startsWith(String)`?
(2) should we deprecate `Path::endsWith(String)`?
(3) should we add a file extension API?

And the TL;DR: no, no, yes.

Let's first establish why `startsWith/endsWith` add tangible value:
because `path.startsWith("foo")` is not equivalent to 
`path.startsWith(Path.of("foo"))`
and is much more readable than 
`path.startsWith(getFileSystem().getPath("foo"))`.

Next, let's consider why people might want to use String-based 
`startsWith/endsWith` testing on Path instances:

* testing file extensions = 99.9999% of the times: covered by 
`FileSystem::getPathMatcher`
* testing name elements = 0.0000999% of the times: covered by `Path`
* any other use cases = ~0% of the times: covered by 
`FileSystem::getPathMatcher`

So it is always possible to do without String conversion.
In fact, it is arguably always a bad idea to do String-based testing,
because `path.toString().endsWith(".java")` will also match a file named 
".java",
which on Linux-like OSes would be considered a hidden file named "java" 
that has no file extension.
So using a dedicated `PathMatcher` for testing file extensions is more 
robust and elegant.

However, when testing file extensions we inevitably start by typing `path.`
(assuming we don't just use a third-party library),
first notice there's no method `getFileExtension` or such,
and then notice `endsWith(String)`
(and maybe we've also noticed `getFileName` and already have 
`path.getFileName().`).
At this point it's pure psychology:
we're looking for a method that behaves like String's `endsWith(String)`,
we're looking at a method with the same method signature,
and we can't imagine that the Path class does *not* have a method to 
test the filename extension,
so surely this must be it.
And obviously we ignore any hints at the contrary
(like our IDE proposing both `endsWith(Path)` and `endsWith(String)` for 
autocompletion).
And we don't bother to read the Javadoc, because in cases like this we 
can easily verify our assumptions with JShell
and equally quickly realize our assumptions are wrong.

So yes, this is a common mistake. But this is actually an argument for 
*not* deprecating it.
Many developers have bumped into this, but as far as I can tell the 
mailing list thread in September was the first in the existence of the API.
And I'm unable to find any previous bug reports either.
And here's why: when we realized our assumptions were wrong, we read the 
Javadoc, realized our mistake, learned from it, and moved on.
The Javadoc is crystal-clear, the method overloads another method with 
the same behavior, it clearly adds value over the other method.
In other words: we conclude "makes sense" and don't see any reason to 
complain.

To turn this common mistake into a rare-if-ever mistake, I see two 
(combinable) options:

* introduce a file extension API
* replace `startsWith/endsWith` with methods `startsWithNames/endsWithNames`

I don't consider deprecating `startsWith/endsWith` without replacement 
an option because:

* these methods add value (as was also argued by Rob Spoor), so it's a 
net loss for the Java SE APIs.
And all the people that are happily using these methods today and are 
unaware of this mailing list thread will be unpleasantly surprised to 
see it deprecated
* this means breaking compilation for everyone that builds with 
"-Werror" and "no usage of deprecated APIs" is a very common policy.
So people will end up adding a duplicate of the deprecated methods in 
their own utility libraries
* this trades one trap for another, much more subtle trap, since people 
will blindly replace `"foo"` with `Path.of("foo")`.
(We're having this very discussion because people don't read Javadoc.
So surely we're not expecting people to read the deprecation text and 
follow the recommendations, are we?)
Eventually they'll notice there's a bug, add `IO.println(foo)` and 
`IO.println(Path.of("foo"))`, notice these both print "foo",
but somehow `foo.endsWith(Path.of("foo"))` results in `false`, 
eventually find the culprit ... and then notice the deprecated 
`endsWith` method did exactly
what they wanted all along
* what would the rationale for the deprecation be? How would you 
document this in the Javadoc?
Now you might still say: "People who were looking for a file extension 
API regularly ended up here. If you're one of them, use Path::toString 
instead."
But once a file extension API will be available, it'll be extremely hard 
to come up with a reasonable justification for the deprecation.
And as argued above, simple String-based comparisons are rarely, if 
ever, the most robust solution
* for `startsWith` in particular: the only argument to deprecate it 
seems to be "for the sake of symmetry"

Anthony

On 1/12/2026 8:36 PM, Stuart Marks wrote:
>
> Let's not tie these two issues together.
>
> The discussion clearly shows that the startsWith/endsWith(String) APIs 
> are a trap that several people have fallen into. On that basis it 
> should be deprecated. (Ordinarily, so as to emit a warning, and not 
> for removal, so there won't be any compatibility issue.)
>
> There is also no requirement that a new API be introduced to replace 
> any deprecated API. As the earlier discussion in the thread shows, 
> both the path-based and the string-based use cases can be written 
> using existing APIs, somewhat less conveniently and more verbosely; 
> but these constructs are much more explicit and so are preferable to 
> the APIs to be deprecated. The deprecation text should steer people 
> toward the preferred constructs.
>
> It would indeed be nice to have a file extension API, but this has 
> been discussed several times and has run aground each time for a 
> variety of reasons. Tying these together will hold up the deprecation 
> for no good reason.
>
> Let's proceed with just the deprecation first and work on the file 
> extension API separately.
>
> s'marks
>
> On 1/11/26 12:45 PM, David Alayachew wrote:
>> Thanks for the response Anthony. Messages have been arriving 
>> out-of-order for me, so I didn't see yours at the time of me writing 
>> that message.
>>
>> I think introducing the file extension API first, then gauging the 
>> need for a deprecation before doing it is fine. Sounds like then that 
>> we are universally agreed on the first step being to add the file 
>> extension API, yes?
>>
>> On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe 
>> <anthonyv.be at outlook.com> wrote:
>>
>>     I dissent. (Apparently my previous message wasn't clear.)
>>
>>     The right order of things is to first introduce a file extension
>>     API. Then see if there's still complaints about
>>     `Path::endsWith(String)`. And only then, if there are, consider
>>     taking action.
>>
>>     In my previous message I've already explained how these methods
>>     add real, tangible value and actually are intuitive.
>>     (Again, ask developers to guess how `A::foo(B)` behaves, given
>>     that both `A::foo(A)` and `B::foo(B)` exist, and a large majority
>>     of them will intuitively guess it converts its `b` argument to an
>>     instance of `A` and passes it on to `A::foo(A)`. And their
>>     intuition would be correct in the case of
>>     `Path::endsWith(String)`. That being said, I'll be the first to
>>     admit that I've also made the mistake of attempting to use
>>     `Path::endsWith(String)` to test the file extension.)
>>
>>     In hindsight, maybe `endsWithNames(String)` would've been a
>>     better choice, but hindsight is 20/20.
>>
>>     Deprecating these methods now is premature. And deprecating them
>>     without replacement methods would result in way more complaints
>>     than there have ever been about `endsWith(String)`.
>>
>>     Anthony
>>
>>     On 1/11/2026 12:19 AM, David Alayachew wrote:
>>>     Of course.
>>>
>>>     I see lots of approvals and not really any dissenters. Are we
>>>     waiting for more responses? Or is there anything we can do to
>>>     kick start this?
>>>
>>>     On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter
>>>     <brian.burkhalter at oracle.com> wrote:
>>>
>>>         Thanks for the corroboration.
>>>
>>>>         On Jan 8, 2026, at 1:50?PM, David Alayachew
>>>>         <davidalayachew at gmail.com> wrote:
>>>>
>>>>         Thanks for reviving this.
>>>>
>>>>         I am perfectly happy with the idea of deprecating the
>>>>         Path.{start,ends}With(String), and then only add the file
>>>>         extension method. Originally, I didn't know that new method
>>>>         was on the table, so I suggested a rename. But the file
>>>>         extension api feels like the superior solution.
>>>>
>>>>         10 times out of 10, if I am calling endsWith, the only time
>>>>         I am not looking for "whole" path elements is when I am
>>>>         looking for a file extension. In every other instance, the
>>>>         api does exactly what I expect and want. And plus,
>>>>         something like looking for a file extension is better off
>>>>         being explicit.
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260113/570192b8/attachment-0001.htm>

From bpb at openjdk.org  Tue Jan 13 22:56:48 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Jan 2026 22:56:48 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v2]
In-Reply-To: <0Ed_q6GbBFLOuUD4mBheZlwITbvSzSvPsk7J51h6ABg=.e4f16f09-fbb5-4291-a010-683681602ddd@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
 <OCOuv6f-NDE3tsPMkJjuc2-HoXgHko4iX5xT80wUgzI=.327586d1-20c4-4b14-a9f8-765302ed46f4@github.com>
 <QbEczWgFKooAnIj9nSy_bAJ0KjDPH_ZSW-bveVILcxo=.fab523d6-cf2a-4a18-9119-fe6acbda3d7b@github.com>
 <0Ed_q6GbBFLOuUD4mBheZlwITbvSzSvPsk7J51h6ABg=.e4f16f09-fbb5-4291-a010-683681602ddd@github.com>
Message-ID: <adyB8zGW3YJoYnk1OeliFAGv7GrFPOXZa-r5v7VhB58=.b7460061-bd04-48e6-93a9-f0eedb5f73f2@github.com>

On Tue, 13 Jan 2026 18:07:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Update looks okay, will you create the CSR for this?
> 
> Yes.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/27178#issuecomment-3746926621

From alan.bateman at oracle.com  Wed Jan 14 07:15:11 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Jan 2026 07:15:11 +0000
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <AM7PPF6DBABEF0E21BF3DDA6EDCA6B5E61FE88EA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
 <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
 <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com>
 <CAA9v-_PUvm+XjATAkTz1QJyv6M2tnYmpdrORMgrxUKZLJ2LCuw@mail.gmail.com>
 <AM7PPF6DBABEF0E7C27EF7A2858B9DBBE2CE880A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_N24Mv5+JabZQHjuyMZVBCHE4c-_y2ByQ6omxQwyYbD3A@mail.gmail.com>
 <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com>
 <AM7PPF6DBABEF0E21BF3DDA6EDCA6B5E61FE88EA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
Message-ID: <74591132-0606-4013-abab-5d71256d6f2a@oracle.com>



On 13/01/2026 20:13, Anthony Vanelverdinghe wrote:
>
> There are 3 questions:
>
> (1) should we deprecate `Path::startsWith(String)`?
> (2) should we deprecate `Path::endsWith(String)`?
> (3) should we add a file extension API?
>
The "plan" is to deprecate startsWith(String) and endsWith(String), and 
to reboot the effort to add the file extension API.

-Alan

From alanb at openjdk.org  Wed Jan 14 07:43:08 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jan 2026 07:43:08 GMT
Subject: RFR: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move [v3]
In-Reply-To: <5vsDiYvGWfGQkFo7cM8e23xeHZCgz-j1e6pvCg2nshs=.f37ce438-55cd-42ba-a394-d1905abd2bbe@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
 <5vsDiYvGWfGQkFo7cM8e23xeHZCgz-j1e6pvCg2nshs=.f37ce438-55cd-42ba-a394-d1905abd2bbe@github.com>
Message-ID: <wuwri7dvgLyDPIFnpIB7byIlCSFsffvUBVrxX2dqg-4=.272da916-0b47-4935-81ca-cacd3d39088f@github.com>

On Tue, 13 Jan 2026 19:05:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `java.nio.file.SecureDirectoryStream.move` so that, instead of throwing a `NullPointerException` if the `targetdir` parameter is `null`, it considers a non-absolute path passed via `targetpath` as being relative to the current working directory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367284: Address comments about test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27178#pullrequestreview-3659304951

From anthonyv.be at outlook.com  Wed Jan 14 10:01:31 2026
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Wed, 14 Jan 2026 11:01:31 +0100
Subject: Can we deprecate Path.endsWith(String)?
In-Reply-To: <74591132-0606-4013-abab-5d71256d6f2a@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
 <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
 <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com>
 <CAA9v-_PUvm+XjATAkTz1QJyv6M2tnYmpdrORMgrxUKZLJ2LCuw@mail.gmail.com>
 <AM7PPF6DBABEF0E7C27EF7A2858B9DBBE2CE880A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_N24Mv5+JabZQHjuyMZVBCHE4c-_y2ByQ6omxQwyYbD3A@mail.gmail.com>
 <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com>
 <AM7PPF6DBABEF0E21BF3DDA6EDCA6B5E61FE88EA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <74591132-0606-4013-abab-5d71256d6f2a@oracle.com>
Message-ID: <AM7PPF6DBABEF0E3414EE678BB27F69DCFDE88FA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>

On 1/14/2026 8:15 AM, Alan Bateman wrote:
> On 13/01/2026 20:13, Anthony Vanelverdinghe wrote:
>> There are 3 questions:
>>
>> (1) should we deprecate `Path::startsWith(String)`?
>> (2) should we deprecate `Path::endsWith(String)`?
>> (3) should we add a file extension API?
>>
> The "plan" is to deprecate startsWith(String) and endsWith(String), 
> and to reboot the effort to add the file extension API.
>
> -Alan


Just for the record, emptying my bag of arguments:

Google's Error Prone has a whole catalog of bug patterns, including 
confusing Java SE APIs. Shall we deprecate all of those as well then? 
And note that it does *not* have a bug pattern for 
`Path::{starts,ends}With`. So nobody at Google ever bothered to add it. 
And nobody outside Google ever bothered to file an issue to add it. 
(Same for SonarQube, SpotBugs, or FindBugs: no pattern for this.)

Virtually every Java developer has made the mistake of using 
`Thread.sleep(5)` to mean "sleep 5 seconds" (which is the behavior in 
pretty much every shell). So why are we not deprecating that method then?

Even `String::endsWith(String)` itself is confusing, since some people 
assume its argument is a regex (as with some other String methods like 
`matches`) [1]. So why not e.g., replace `String::matches(String)` with 
`String::matches(Pattern)`?

[1] 
https://stackoverflow.com/questions/9943609/checking-if-string-ends-with-something-with-java-regex

Anthony


From stuart.marks at oracle.com  Wed Jan 14 18:20:19 2026
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 14 Jan 2026 10:20:19 -0800
Subject: [External] : Re: Can we deprecate Path.endsWith(String)?
In-Reply-To: <AM7PPF6DBABEF0E21BF3DDA6EDCA6B5E61FE88EA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <A07794CB-3790-461C-A8E9-CE3E751EC7B3@oracle.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
 <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
 <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com>
 <CAA9v-_PUvm+XjATAkTz1QJyv6M2tnYmpdrORMgrxUKZLJ2LCuw@mail.gmail.com>
 <AM7PPF6DBABEF0E7C27EF7A2858B9DBBE2CE880A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_N24Mv5+JabZQHjuyMZVBCHE4c-_y2ByQ6omxQwyYbD3A@mail.gmail.com>
 <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com>
 <AM7PPF6DBABEF0E21BF3DDA6EDCA6B5E61FE88EA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
Message-ID: <1867a1b2-d534-47c7-9554-3188a86bc60f@oracle.com>

You're making this too complicated.

On their face, startsWith/endsWith(String) are misleading to both code authors and 
code readers, and that justifies their deprecation. It will help code authors avoid 
making new mistakes. Readers of code that uses these APIs -- even correctly -- can 
easily misinterpret the code as if it performed string-based testing and thus be 
misled about what the code is actually doing. In both cases, the code is better 
replaced with more explicit, if more verbose, alternatives that already exist.

Certainly a file extension API would facilitate use cases that involve file 
extensions, such as inspecting a file's extension to determine how to process the 
file. I'm in favor of adding such an API. But that's a different topic from this 
one, and it should be handled independently.

I did read all of your message but I'm not responding to most of it, because it 
doesn't establish a dependency between these two topics.

s'marks

On 1/13/26 12:13 PM, Anthony Vanelverdinghe wrote:
>
> There are 3 questions:
>
> (1) should we deprecate `Path::startsWith(String)`?
> (2) should we deprecate `Path::endsWith(String)`?
> (3) should we add a file extension API?
>
> And the TL;DR: no, no, yes.
>
> Let's first establish why `startsWith/endsWith` add tangible value:
> because `path.startsWith("foo")` is not equivalent to 
> `path.startsWith(Path.of("foo"))`
> and is much more readable than `path.startsWith(getFileSystem().getPath("foo"))`.
>
> Next, let's consider why people might want to use String-based 
> `startsWith/endsWith` testing on Path instances:
>
> * testing file extensions = 99.9999% of the times: covered by 
> `FileSystem::getPathMatcher`
> * testing name elements = 0.0000999% of the times: covered by `Path`
> * any other use cases = ~0% of the times: covered by `FileSystem::getPathMatcher`
>
> So it is always possible to do without String conversion.
> In fact, it is arguably always a bad idea to do String-based testing,
> because `path.toString().endsWith(".java")` will also match a file named ".java",
> which on Linux-like OSes would be considered a hidden file named "java" that has 
> no file extension.
> So using a dedicated `PathMatcher` for testing file extensions is more robust and 
> elegant.
>
> However, when testing file extensions we inevitably start by typing `path.`
> (assuming we don't just use a third-party library),
> first notice there's no method `getFileExtension` or such,
> and then notice `endsWith(String)`
> (and maybe we've also noticed `getFileName` and already have `path.getFileName().`).
> At this point it's pure psychology:
> we're looking for a method that behaves like String's `endsWith(String)`,
> we're looking at a method with the same method signature,
> and we can't imagine that the Path class does *not* have a method to test the 
> filename extension,
> so surely this must be it.
> And obviously we ignore any hints at the contrary
> (like our IDE proposing both `endsWith(Path)` and `endsWith(String)` for 
> autocompletion).
> And we don't bother to read the Javadoc, because in cases like this we can easily 
> verify our assumptions with JShell
> and equally quickly realize our assumptions are wrong.
>
> So yes, this is a common mistake. But this is actually an argument for *not* 
> deprecating it.
> Many developers have bumped into this, but as far as I can tell the mailing list 
> thread in September was the first in the existence of the API.
> And I'm unable to find any previous bug reports either.
> And here's why: when we realized our assumptions were wrong, we read the Javadoc, 
> realized our mistake, learned from it, and moved on.
> The Javadoc is crystal-clear, the method overloads another method with the same 
> behavior, it clearly adds value over the other method.
> In other words: we conclude "makes sense" and don't see any reason to complain.
>
> To turn this common mistake into a rare-if-ever mistake, I see two (combinable) 
> options:
>
> * introduce a file extension API
> * replace `startsWith/endsWith` with methods `startsWithNames/endsWithNames`
>
> I don't consider deprecating `startsWith/endsWith` without replacement an option 
> because:
>
> * these methods add value (as was also argued by Rob Spoor), so it's a net loss 
> for the Java SE APIs.
> And all the people that are happily using these methods today and are unaware of 
> this mailing list thread will be unpleasantly surprised to see it deprecated
> * this means breaking compilation for everyone that builds with "-Werror" and "no 
> usage of deprecated APIs" is a very common policy.
> So people will end up adding a duplicate of the deprecated methods in their own 
> utility libraries
> * this trades one trap for another, much more subtle trap, since people will 
> blindly replace `"foo"` with `Path.of("foo")`.
> (We're having this very discussion because people don't read Javadoc.
> So surely we're not expecting people to read the deprecation text and follow the 
> recommendations, are we?)
> Eventually they'll notice there's a bug, add `IO.println(foo)` and 
> `IO.println(Path.of("foo"))`, notice these both print "foo",
> but somehow `foo.endsWith(Path.of("foo"))` results in `false`, eventually find the 
> culprit ... and then notice the deprecated `endsWith` method did exactly
> what they wanted all along
> * what would the rationale for the deprecation be? How would you document this in 
> the Javadoc?
> Now you might still say: "People who were looking for a file extension API 
> regularly ended up here. If you're one of them, use Path::toString instead."
> But once a file extension API will be available, it'll be extremely hard to come 
> up with a reasonable justification for the deprecation.
> And as argued above, simple String-based comparisons are rarely, if ever, the most 
> robust solution
> * for `startsWith` in particular: the only argument to deprecate it seems to be 
> "for the sake of symmetry"
>
> Anthony
>
> On 1/12/2026 8:36 PM, Stuart Marks wrote:
>>
>> Let's not tie these two issues together.
>>
>> The discussion clearly shows that the startsWith/endsWith(String) APIs are a trap 
>> that several people have fallen into. On that basis it should be deprecated. 
>> (Ordinarily, so as to emit a warning, and not for removal, so there won't be any 
>> compatibility issue.)
>>
>> There is also no requirement that a new API be introduced to replace any 
>> deprecated API. As the earlier discussion in the thread shows, both the 
>> path-based and the string-based use cases can be written using existing APIs, 
>> somewhat less conveniently and more verbosely; but these constructs are much more 
>> explicit and so are preferable to the APIs to be deprecated. The deprecation text 
>> should steer people toward the preferred constructs.
>>
>> It would indeed be nice to have a file extension API, but this has been discussed 
>> several times and has run aground each time for a variety of reasons. Tying these 
>> together will hold up the deprecation for no good reason.
>>
>> Let's proceed with just the deprecation first and work on the file extension API 
>> separately.
>>
>> s'marks
>>
>> On 1/11/26 12:45 PM, David Alayachew wrote:
>>> Thanks for the response Anthony. Messages have been arriving out-of-order for 
>>> me, so I didn't see yours at the time of me writing that message.
>>>
>>> I think introducing the file extension API first, then gauging the need for a 
>>> deprecation before doing it is fine. Sounds like then that we are universally 
>>> agreed on the first step being to add the file extension API, yes?
>>>
>>> On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe <anthonyv.be at outlook.com> 
>>> wrote:
>>>
>>>     I dissent. (Apparently my previous message wasn't clear.)
>>>
>>>     The right order of things is to first introduce a file extension API. Then
>>>     see if there's still complaints about `Path::endsWith(String)`. And only
>>>     then, if there are, consider taking action.
>>>
>>>     In my previous message I've already explained how these methods add real,
>>>     tangible value and actually are intuitive.
>>>     (Again, ask developers to guess how `A::foo(B)` behaves, given that both
>>>     `A::foo(A)` and `B::foo(B)` exist, and a large majority of them will
>>>     intuitively guess it converts its `b` argument to an instance of `A` and
>>>     passes it on to `A::foo(A)`. And their intuition would be correct in the
>>>     case of `Path::endsWith(String)`. That being said, I'll be the first to
>>>     admit that I've also made the mistake of attempting to use
>>>     `Path::endsWith(String)` to test the file extension.)
>>>
>>>     In hindsight, maybe `endsWithNames(String)` would've been a better choice,
>>>     but hindsight is 20/20.
>>>
>>>     Deprecating these methods now is premature. And deprecating them without
>>>     replacement methods would result in way more complaints than there have ever
>>>     been about `endsWith(String)`.
>>>
>>>     Anthony
>>>
>>>     On 1/11/2026 12:19 AM, David Alayachew wrote:
>>>>     Of course.
>>>>
>>>>     I see lots of approvals and not really any dissenters. Are we waiting for
>>>>     more responses? Or is there anything we can do to kick start this?
>>>>
>>>>     On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter
>>>>     <brian.burkhalter at oracle.com> wrote:
>>>>
>>>>         Thanks for the corroboration.
>>>>
>>>>>         On Jan 8, 2026, at 1:50?PM, David Alayachew <davidalayachew at gmail.com>
>>>>>         wrote:
>>>>>
>>>>>         Thanks for reviving this.
>>>>>
>>>>>         I am perfectly happy with the idea of deprecating the
>>>>>         Path.{start,ends}With(String), and then only add the file extension
>>>>>         method. Originally, I didn't know that new method was on the table, so
>>>>>         I suggested a rename. But the file extension api feels like the
>>>>>         superior solution.
>>>>>
>>>>>         10 times out of 10, if I am calling endsWith, the only time I am not
>>>>>         looking for "whole" path elements is when I am looking for a file
>>>>>         extension. In every other instance, the api does exactly what I expect
>>>>>         and want. And plus, something like looking for a file extension is
>>>>>         better off being explicit.
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260114/66170ac9/attachment-0001.htm>

From bpb at openjdk.org  Wed Jan 14 18:35:06 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 Jan 2026 18:35:06 GMT
Subject: RFR: 8375294: (fs) Files.copy can fail with EOPNOTSUPP when
 copy_file_range not supported
Message-ID: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>

Handle `errno` value `EOPNOTSUPP` for `copy_file_range` system call on Linux.

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

Commit messages:
 - 8375294: (fs) Files.copy can fail with EOPNOTSUPP when copy_file_range not supported

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

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

From bpb at openjdk.org  Wed Jan 14 18:35:07 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 Jan 2026 18:35:07 GMT
Subject: RFR: 8375294: (fs) Files.copy can fail with EOPNOTSUPP when
 copy_file_range not supported
In-Reply-To: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
References: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
Message-ID: <lj9Hu2zu75cVA0b91p_FXE9wBNUdFMQbXJakP2bjlME=.c6dcc9a7-a001-49ad-93ba-ea4fa90b8440@github.com>

On Wed, 14 Jan 2026 18:26:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Handle `errno` value `EOPNOTSUPP` for `copy_file_range` system call on Linux.

It does not verify this fix, but the Linux aarch64 and x64 builds succeeded and the jdk_nio tests passed on these platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/29234#issuecomment-3751004623

From alanb at openjdk.org  Wed Jan 14 18:56:59 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jan 2026 18:56:59 GMT
Subject: RFR: 8375294: (fs) Files.copy can fail with EOPNOTSUPP when
 copy_file_range not supported
In-Reply-To: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
References: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
Message-ID: <6oUbp207PXCbwesQGg-GJjmgr6EsFDOpwu8aXvcW6CM=.15ba5a94-601e-46ac-8b74-60eacc356dcd@github.com>

On Wed, 14 Jan 2026 18:26:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Handle `errno` value `EOPNOTSUPP` for `copy_file_range` system call on Linux.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29234#pullrequestreview-3662282642

From bpb at openjdk.org  Wed Jan 14 22:27:04 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 Jan 2026 22:27:04 GMT
Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for
 symbolic links in a mapped drive (win) [v3]
In-Reply-To: <FF548_dJBqnugMihCRQWlNtY5W_BHCSXmX4UqntgZ_c=.5082b69b-e9db-4c28-9603-14f551f09623@github.com>
References: <FF548_dJBqnugMihCRQWlNtY5W_BHCSXmX4UqntgZ_c=.5082b69b-e9db-4c28-9603-14f551f09623@github.com>
Message-ID: <n2NDZm9xydm3sgbRuGGE7RLLvTRJU1-_lA9DkRLEuqs=.527acecd-d626-4345-9192-ab37fd7397ac@github.com>

> If `getFinalPath` throws an exception, or converts a drive path to a UNC path, then fall back to the slow path which uses `resolveAllLinks`.

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
 - 8368165: Improve fallback mechanism when a link cannot be opened for attribute access
 - 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28032/files
  - new: https://git.openjdk.org/jdk/pull/28032/files/891561f6..ba3952dc

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

  Stats: 413918 lines in 6117 files changed: 261573 ins; 88231 del; 64114 mod
  Patch: https://git.openjdk.org/jdk/pull/28032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28032/head:pull/28032

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

From jpai at openjdk.org  Thu Jan 15 06:56:52 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Jan 2026 06:56:52 GMT
Subject: RFR: 8375294: (fs) Files.copy can fail with EOPNOTSUPP when
 copy_file_range not supported
In-Reply-To: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
References: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
Message-ID: <BDIX2GUdpLDeqqkVs20FCdzVId5XZ7tey6h8CNUzn3w=.a04f1cde-aa75-414b-a671-a76ea372f5ad@github.com>

On Wed, 14 Jan 2026 18:26:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Handle `errno` value `EOPNOTSUPP` for `copy_file_range` system call on Linux.

Hello Brian, the change looks good to me. Interestingly `man copy_file_range` doesn't make a mention of this `errno`. Looking at `man errno` it says:


ENOSYS          Function not implemented (POSIX.1-2001).
...
ENOTSUP         Operation not supported (POSIX.1-2001).
...
EOPNOTSUPP      Operation not supported on socket (POSIX.1-2001).
                (ENOTSUP and EOPNOTSUPP have the same value on Linux, but according to POSIX.1 these error values should be distinct.)


Given this, do you think we should also include `ENOTSUP` in this change?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29234#pullrequestreview-3664172712

From alanb at openjdk.org  Thu Jan 15 07:36:34 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jan 2026 07:36:34 GMT
Subject: RFR: 8375294: (fs) Files.copy can fail with EOPNOTSUPP when
 copy_file_range not supported
In-Reply-To: <BDIX2GUdpLDeqqkVs20FCdzVId5XZ7tey6h8CNUzn3w=.a04f1cde-aa75-414b-a671-a76ea372f5ad@github.com>
References: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
 <BDIX2GUdpLDeqqkVs20FCdzVId5XZ7tey6h8CNUzn3w=.a04f1cde-aa75-414b-a671-a76ea372f5ad@github.com>
Message-ID: <9lzzzF5TLcF29JhO_2oienTkouGzTolPO9F82nEXNJ8=.ea589133-3edf-491a-b4bf-bfdc473e96e8@github.com>

On Thu, 15 Jan 2026 06:52:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Brian, the change looks good to me. Interestingly `man copy_file_range` doesn't make a mention of this `errno`. 

I was chatting with Brain yesterday about this as EOPNOTSUPP doesn't seem to have originally listed in the Linux man page. It does list is now. It does not list ENOTSUP (which as you note has the same value on Linux). Right now, the usage is in Linux specific code. If it were to move to the "unix" tree for use by other Unix platforms then I think the possible errors would need to be double checked.

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

PR Comment: https://git.openjdk.org/jdk/pull/29234#issuecomment-3753250259

From jpai at openjdk.org  Thu Jan 15 09:48:10 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Jan 2026 09:48:10 GMT
Subject: RFR: 8375294: (fs) Files.copy can fail with EOPNOTSUPP when
 copy_file_range not supported
In-Reply-To: <9lzzzF5TLcF29JhO_2oienTkouGzTolPO9F82nEXNJ8=.ea589133-3edf-491a-b4bf-bfdc473e96e8@github.com>
References: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
 <BDIX2GUdpLDeqqkVs20FCdzVId5XZ7tey6h8CNUzn3w=.a04f1cde-aa75-414b-a671-a76ea372f5ad@github.com>
 <9lzzzF5TLcF29JhO_2oienTkouGzTolPO9F82nEXNJ8=.ea589133-3edf-491a-b4bf-bfdc473e96e8@github.com>
Message-ID: <NSSNdh3hJVoDB0fyDaqwJQDmsWIyYcyIJAeZtxUdmoU=.b402235c-9850-4446-94bc-5b90e9dae055@github.com>

On Thu, 15 Jan 2026 07:33:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  Right now, the usage is in Linux specific code. If it were to move to the "unix" tree for use by other Unix platforms then I think the possible errors would need to be double checked.

That sounds fine to me. Thank you Alan.

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

PR Comment: https://git.openjdk.org/jdk/pull/29234#issuecomment-3753811687

From anthonyv.be at outlook.com  Thu Jan 15 13:56:08 2026
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Thu, 15 Jan 2026 14:56:08 +0100
Subject: [External] : Re: Can we deprecate Path.endsWith(String)?
In-Reply-To: <1867a1b2-d534-47c7-9554-3188a86bc60f@oracle.com>
References: <CAA9v-_MNGsX1A=Tn=NwiDAwmWboMQRmczo+LWCZHfPeRiVVZ0Q@mail.gmail.com>
 <CAL5bRt9EeLUgDCAGq988J9i-gNmDGeoMTFsTFZQV49O2fr6P9g@mail.gmail.com>
 <DBE6A698-489E-4A6E-8A51-77231123DE85@oracle.com>
 <B325BBEF-4494-4BEF-A880-01ECB680459A@oracle.com>
 <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com>
 <db156f43-426c-47e8-9908-0a45c229ce80@oracle.com>
 <AM7PPF6DBABEF0E57369CCD282238D83558E885A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_MwXVJ3fKDmGrOFF9PQCoQ-mE=rO4aH-GEbP4BxSyfnLw@mail.gmail.com>
 <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com>
 <CAA9v-_PUvm+XjATAkTz1QJyv6M2tnYmpdrORMgrxUKZLJ2LCuw@mail.gmail.com>
 <AM7PPF6DBABEF0E7C27EF7A2858B9DBBE2CE880A@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <CAA9v-_N24Mv5+JabZQHjuyMZVBCHE4c-_y2ByQ6omxQwyYbD3A@mail.gmail.com>
 <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com>
 <AM7PPF6DBABEF0E21BF3DDA6EDCA6B5E61FE88EA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>
 <1867a1b2-d534-47c7-9554-3188a86bc60f@oracle.com>
Message-ID: <AM7PPF6DBABEF0E3A3C71BBF080FC9729F8E88CA@AM7PPF6DBABEF0E.EURP189.PROD.OUTLOOK.COM>

Thank you for taking the time to clarify the trade-offs, especially 
highlighting the importance of code readers and readability.

Please bear with me and allow me to express my point of view in terms of 
code authors and code readers.

Regarding code authors, I hold that when they are misled, they were 
looking for a file extension API in virtually all cases. So I see a 
dependency here in that adding a file extension API would reduce the 
number of misleads to a negligible frequency, no larger than the 
frequency with other Java SE APIs. For example, being misled to write 
`Duration.from(aPeriod)`.
By deprecating these methods, I believe code authors will be misled to 
simply write `path.endsWith(Path.of("foo"))`, without considering 
alternative file systems (AFSs). Even code authors that actually know 
about AFSs, as it's a subtle consideration that is easily overlooked. 
And this will in turn impact code readers as well, as they'll wonder 
whether it is acceptable to ignore AFSs (unless the code author 
documented why it is). With `path.endsWith("foo")`, authors don't have 
to document anything and readers don't have to wonder: it just works.

Regarding code readers, I hold that it is rare to be misled and that the 
code author is best placed to judge whether `path.endsWith("foo")` is 
misleading. For example, code readers would readily see that 
`Files.isDirectory(path) && path.endsWith(".git")` looks for Git 
repositories. And in cases where the code author considers 
`path.endsWith("foo")` to be misleading, they'd simply introduce a 
variable to eliminate any confusion, e.g., `var filename = "foo"; 
path.endsWith(filename)`.
By deprecating these methods, code authors have one less tool for 
writing readable code. Since something like 
`path.endsWith(path.getFileSystem().getPath("foo"))` can hardly be 
considered readable, either code authors have to constrain their code to 
the default file system, or they have to introduce a new local variable 
for the argument to `endsWith`. In case of the former, code readers may 
be left to wonder whether it is acceptable to ignore AFSs (as explained 
above). In case of the latter, code readers might be misled to simplify 
`var foo = path.getFileSystem().getPath("foo")` to `var foo = 
Path.of("foo")`, thinking these are equivalent.

Thanks again for reading. I don't mean to drag on the discussion, so if 
there's nothing in here that you hadn't already considered, we can leave 
it at this.

Kind regards, Anthony

On 1/14/2026 7:20 PM, Stuart Marks wrote:
>
> You're making this too complicated.
>
> On their face, startsWith/endsWith(String) are misleading to both code 
> authors and code readers, and that justifies their deprecation. It 
> will help code authors avoid making new mistakes. Readers of code that 
> uses these APIs -- even correctly -- can easily misinterpret the code 
> as if it performed string-based testing and thus be misled about what 
> the code is actually doing. In both cases, the code is better replaced 
> with more explicit, if more verbose, alternatives that already exist.
>
> Certainly a file extension API would facilitate use cases that involve 
> file extensions, such as inspecting a file's extension to determine 
> how to process the file. I'm in favor of adding such an API. But 
> that's a different topic from this one, and it should be handled 
> independently.
>
> I did read all of your message but I'm not responding to most of it, 
> because it doesn't establish a dependency between these two topics.
>
> s'marks
>
> On 1/13/26 12:13 PM, Anthony Vanelverdinghe wrote:
>>
>> There are 3 questions:
>>
>> (1) should we deprecate `Path::startsWith(String)`?
>> (2) should we deprecate `Path::endsWith(String)`?
>> (3) should we add a file extension API?
>>
>> And the TL;DR: no, no, yes.
>>
>> Let's first establish why `startsWith/endsWith` add tangible value:
>> because `path.startsWith("foo")` is not equivalent to 
>> `path.startsWith(Path.of("foo"))`
>> and is much more readable than 
>> `path.startsWith(getFileSystem().getPath("foo"))`.
>>
>> Next, let's consider why people might want to use String-based 
>> `startsWith/endsWith` testing on Path instances:
>>
>> * testing file extensions = 99.9999% of the times: covered by 
>> `FileSystem::getPathMatcher`
>> * testing name elements = 0.0000999% of the times: covered by `Path`
>> * any other use cases = ~0% of the times: covered by 
>> `FileSystem::getPathMatcher`
>>
>> So it is always possible to do without String conversion.
>> In fact, it is arguably always a bad idea to do String-based testing,
>> because `path.toString().endsWith(".java")` will also match a file 
>> named ".java",
>> which on Linux-like OSes would be considered a hidden file named 
>> "java" that has no file extension.
>> So using a dedicated `PathMatcher` for testing file extensions is 
>> more robust and elegant.
>>
>> However, when testing file extensions we inevitably start by typing 
>> `path.`
>> (assuming we don't just use a third-party library),
>> first notice there's no method `getFileExtension` or such,
>> and then notice `endsWith(String)`
>> (and maybe we've also noticed `getFileName` and already have 
>> `path.getFileName().`).
>> At this point it's pure psychology:
>> we're looking for a method that behaves like String's `endsWith(String)`,
>> we're looking at a method with the same method signature,
>> and we can't imagine that the Path class does *not* have a method to 
>> test the filename extension,
>> so surely this must be it.
>> And obviously we ignore any hints at the contrary
>> (like our IDE proposing both `endsWith(Path)` and `endsWith(String)` 
>> for autocompletion).
>> And we don't bother to read the Javadoc, because in cases like this 
>> we can easily verify our assumptions with JShell
>> and equally quickly realize our assumptions are wrong.
>>
>> So yes, this is a common mistake. But this is actually an argument 
>> for *not* deprecating it.
>> Many developers have bumped into this, but as far as I can tell the 
>> mailing list thread in September was the first in the existence of 
>> the API.
>> And I'm unable to find any previous bug reports either.
>> And here's why: when we realized our assumptions were wrong, we read 
>> the Javadoc, realized our mistake, learned from it, and moved on.
>> The Javadoc is crystal-clear, the method overloads another method 
>> with the same behavior, it clearly adds value over the other method.
>> In other words: we conclude "makes sense" and don't see any reason to 
>> complain.
>>
>> To turn this common mistake into a rare-if-ever mistake, I see two 
>> (combinable) options:
>>
>> * introduce a file extension API
>> * replace `startsWith/endsWith` with methods 
>> `startsWithNames/endsWithNames`
>>
>> I don't consider deprecating `startsWith/endsWith` without 
>> replacement an option because:
>>
>> * these methods add value (as was also argued by Rob Spoor), so it's 
>> a net loss for the Java SE APIs.
>> And all the people that are happily using these methods today and are 
>> unaware of this mailing list thread will be unpleasantly surprised to 
>> see it deprecated
>> * this means breaking compilation for everyone that builds with 
>> "-Werror" and "no usage of deprecated APIs" is a very common policy.
>> So people will end up adding a duplicate of the deprecated methods in 
>> their own utility libraries
>> * this trades one trap for another, much more subtle trap, since 
>> people will blindly replace `"foo"` with `Path.of("foo")`.
>> (We're having this very discussion because people don't read Javadoc.
>> So surely we're not expecting people to read the deprecation text and 
>> follow the recommendations, are we?)
>> Eventually they'll notice there's a bug, add `IO.println(foo)` and 
>> `IO.println(Path.of("foo"))`, notice these both print "foo",
>> but somehow `foo.endsWith(Path.of("foo"))` results in `false`, 
>> eventually find the culprit ... and then notice the deprecated 
>> `endsWith` method did exactly
>> what they wanted all along
>> * what would the rationale for the deprecation be? How would you 
>> document this in the Javadoc?
>> Now you might still say: "People who were looking for a file 
>> extension API regularly ended up here. If you're one of them, use 
>> Path::toString instead."
>> But once a file extension API will be available, it'll be extremely 
>> hard to come up with a reasonable justification for the deprecation.
>> And as argued above, simple String-based comparisons are rarely, if 
>> ever, the most robust solution
>> * for `startsWith` in particular: the only argument to deprecate it 
>> seems to be "for the sake of symmetry"
>>
>> Anthony
>>
>> On 1/12/2026 8:36 PM, Stuart Marks wrote:
>>>
>>> Let's not tie these two issues together.
>>>
>>> The discussion clearly shows that the startsWith/endsWith(String) 
>>> APIs are a trap that several people have fallen into. On that basis 
>>> it should be deprecated. (Ordinarily, so as to emit a warning, and 
>>> not for removal, so there won't be any compatibility issue.)
>>>
>>> There is also no requirement that a new API be introduced to replace 
>>> any deprecated API. As the earlier discussion in the thread shows, 
>>> both the path-based and the string-based use cases can be written 
>>> using existing APIs, somewhat less conveniently and more verbosely; 
>>> but these constructs are much more explicit and so are preferable to 
>>> the APIs to be deprecated. The deprecation text should steer people 
>>> toward the preferred constructs.
>>>
>>> It would indeed be nice to have a file extension API, but this has 
>>> been discussed several times and has run aground each time for a 
>>> variety of reasons. Tying these together will hold up the 
>>> deprecation for no good reason.
>>>
>>> Let's proceed with just the deprecation first and work on the file 
>>> extension API separately.
>>>
>>> s'marks
>>>
>>> On 1/11/26 12:45 PM, David Alayachew wrote:
>>>> Thanks for the response Anthony. Messages have been arriving 
>>>> out-of-order for me, so I didn't see yours at the time of me 
>>>> writing that message.
>>>>
>>>> I think introducing the file extension API first, then gauging the 
>>>> need for a deprecation before doing it is fine. Sounds like then 
>>>> that we are universally agreed on the first step being to add the 
>>>> file extension API, yes?
>>>>
>>>> On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe 
>>>> <anthonyv.be at outlook.com> wrote:
>>>>
>>>>     I dissent. (Apparently my previous message wasn't clear.)
>>>>
>>>>     The right order of things is to first introduce a file
>>>>     extension API. Then see if there's still complaints about
>>>>     `Path::endsWith(String)`. And only then, if there are, consider
>>>>     taking action.
>>>>
>>>>     In my previous message I've already explained how these methods
>>>>     add real, tangible value and actually are intuitive.
>>>>     (Again, ask developers to guess how `A::foo(B)` behaves, given
>>>>     that both `A::foo(A)` and `B::foo(B)` exist, and a large
>>>>     majority of them will intuitively guess it converts its `b`
>>>>     argument to an instance of `A` and passes it on to `A::foo(A)`.
>>>>     And their intuition would be correct in the case of
>>>>     `Path::endsWith(String)`. That being said, I'll be the first to
>>>>     admit that I've also made the mistake of attempting to use
>>>>     `Path::endsWith(String)` to test the file extension.)
>>>>
>>>>     In hindsight, maybe `endsWithNames(String)` would've been a
>>>>     better choice, but hindsight is 20/20.
>>>>
>>>>     Deprecating these methods now is premature. And deprecating
>>>>     them without replacement methods would result in way more
>>>>     complaints than there have ever been about `endsWith(String)`.
>>>>
>>>>     Anthony
>>>>
>>>>     On 1/11/2026 12:19 AM, David Alayachew wrote:
>>>>>     Of course.
>>>>>
>>>>>     I see lots of approvals and not really any dissenters. Are we
>>>>>     waiting for more responses? Or is there anything we can do to
>>>>>     kick start this?
>>>>>
>>>>>     On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter
>>>>>     <brian.burkhalter at oracle.com> wrote:
>>>>>
>>>>>         Thanks for the corroboration.
>>>>>
>>>>>>         On Jan 8, 2026, at 1:50?PM, David Alayachew
>>>>>>         <davidalayachew at gmail.com> wrote:
>>>>>>
>>>>>>         Thanks for reviving this.
>>>>>>
>>>>>>         I am perfectly happy with the idea of deprecating the
>>>>>>         Path.{start,ends}With(String), and then only add the file
>>>>>>         extension method. Originally, I didn't know that new
>>>>>>         method was on the table, so I suggested a rename. But the
>>>>>>         file extension api feels like the superior solution.
>>>>>>
>>>>>>         10 times out of 10, if I am calling endsWith, the only
>>>>>>         time I am not looking for "whole" path elements is when I
>>>>>>         am looking for a file extension. In every other instance,
>>>>>>         the api does exactly what I expect and want. And plus,
>>>>>>         something like looking for a file extension is better off
>>>>>>         being explicit.
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260115/b85795f3/attachment-0001.htm>

From bpb at openjdk.org  Thu Jan 15 17:19:14 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 Jan 2026 17:19:14 GMT
Subject: RFR: 8375294: (fs) Files.copy can fail with EOPNOTSUPP when
 copy_file_range not supported
In-Reply-To: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
References: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
Message-ID: <z16Xu3zbIOcqPYg5zVauAaJGqW0CTYh5R1v7RhSiqmY=.2b77e6c7-1327-4519-9633-803336dc4ce3@github.com>

On Wed, 14 Jan 2026 18:26:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Handle `errno` value `EOPNOTSUPP` for `copy_file_range` system call on Linux.

Man page of [copy_file_range(2)](https://www.man7.org/linux/man-pages/man2/copy_file_range.2.html).

The submitter verified the patch so I think we can go with this.

Thanks for the comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/29234#issuecomment-3755990193

From bpb at openjdk.org  Thu Jan 15 19:34:39 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 Jan 2026 19:34:39 GMT
Subject: Integrated: 8375294: (fs) Files.copy can fail with EOPNOTSUPP when
 copy_file_range not supported
In-Reply-To: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
References: <mGzagwk3vbC65T1eHOCGrIQlA-P05X2DltFKO6QcwXA=.d183de7c-647c-452f-ab3f-5e3b03dc0f53@github.com>
Message-ID: <XMfZ5Cjd1sldhhYp7Vg-mASm7dg34xIss4fJcx6UrOA=.4ad4ddd5-67f7-41aa-ab09-95a75c2329ec@github.com>

On Wed, 14 Jan 2026 18:26:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Handle `errno` value `EOPNOTSUPP` for `copy_file_range` system call on Linux.

This pull request has now been integrated.

Changeset: 30cda000
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30cda00010888b6e9a2bf8cdeaedbb3eb4b6a222
Stats:     5 lines in 2 files changed: 2 ins; 0 del; 3 mod

8375294: (fs) Files.copy can fail with EOPNOTSUPP when copy_file_range not supported

Reviewed-by: alanb, jpai

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

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

From smonteith at openjdk.org  Tue Jan 20 09:37:08 2026
From: smonteith at openjdk.org (Stuart Monteith)
Date: Tue, 20 Jan 2026 09:37:08 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>
Message-ID: <uTpKLMgW_uKXr9vk2F5y8xjq33HBF4yLTvw0XFh8nt8=.617dded6-0b66-40dc-829a-0ae711a1d4b9@github.com>

On Thu, 4 Dec 2025 16:22:08 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

>> MemorySegments allocated from shared Arena from
>> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
>> 
>> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
>> 
>> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
>> 
>> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
>> |---------|-------|-------|-------|-------|-------|-------|
>> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
>> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
>> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
>> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
>> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
>> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
>> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
>> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
>> 
>> After:
>> 
>> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
>> |---------|-------|-------|-------|-------|-------|-------|
>> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
>> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
>> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
>> |    8  |    58...
>
> I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion.

> @stooart-mon This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a `/touch` or `/keepalive` command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

It's OK bot, I'm sure people are looking at this.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3771899705

From dfenacci at openjdk.org  Tue Jan 20 18:54:04 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 20 Jan 2026 18:54:04 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
Message-ID: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>

## Issue

This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.

This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.

## Causes

The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.

## Fix

A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.

# Testing

* Tier 1-3+
* 2 JTReg tests added
  * `TestRangeCheck.java` as regression test for the reported issue
  * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

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

Commit messages:
 - JDK-8374852: revert unchanged tests
 - JDK-8374852: shorten line lenght in test
 - JDK-8374852: revert comment change
 - JDK-8374852: correct  comment and make more concise
 - Update test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java
 - JDK-8374852: fix generate_limit_guard opaque handling and remove unneeded positive flag
 - JDK-8374852: remove compileonly
 - JDK-8374852: remove VerifyIntrinsicChecks and refactor opaque flag
 - JDK-8374852: add forgotten opaque guard node handling in clone_iff
 - JDK-8374852: 120 max char for comment
 - ... and 8 more: https://git.openjdk.org/jdk/compare/6d1bfdf7...ff228576

Changes: https://git.openjdk.org/jdk/pull/29164/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374582
  Stats: 435 lines in 28 files changed: 328 ins; 20 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

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

From vyazici at openjdk.org  Tue Jan 20 18:54:09 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 Jan 2026 18:54:09 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>

On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Marked as reviewed by vyazici (Committer).

Verified that 3c466d372b7 is a clean revert of 7e18de137c3 delivered in [JDK-8374210].

[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

src/hotspot/share/opto/c2_globals.hpp line 680:

> 678:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 679:           "Verify in intrinsic that Java level checks work as expected")    \
> 680:                                                                             \

I suggest removing the `VerifyIntrinsicChecks` flag. Given `OpaqueGuard` already verifies the value when `#ifdef ASSERT`, does `VerifyIntrinsicChecks` serve any purpose anymore?

src/hotspot/share/opto/library_call.hpp line 170:

> 168:                                     Node* length, bool char_count,
> 169:                                     bool halt_on_oob = false,
> 170:                                     bool is_opaque = false);

Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used:

1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks`
2. defaults (i.e., `halt_on_oob=is_opaque=false`)

Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`?

src/hotspot/share/opto/loopopts.cpp line 1:

> 1: /*

What is the reason that the new `OpaqueGuard` is not taken into account in `PhaseIdealLoop::clone_iff`?

src/hotspot/share/opto/macro.cpp line 2565:

> 2563:         // Tests with OpaqueGuard nodes are implicitly known to be true or false. Replace the node with appropriate value. In debug builds,
> 2564:         // we leave the test in the graph to have an additional sanity check at runtime. If the test fails (i.e. a bug),
> 2565:         // we will execute a Halt node.

*Nit:* Can we adhere to the max. 120 (or even better, 80!) characters per line limit of the file?

src/hotspot/share/opto/macro.cpp line 2569:

> 2567:         _igvn.replace_node(n, n->in(1));
> 2568: #else
> 2569:         _igvn.replace_node(n, _igvn.intcon(0));

Curious: why do we invoke `intcon(0)` for `OpaqueGuard`, whereas it was `intcon(1)` for `OpaqueNotNull` slightly above?

src/hotspot/share/opto/opaquenode.hpp line 160:

> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode
> 159: // inputs instead).
> 160: class OpaqueGuardNode : public Node {

With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of?

test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 1:

> 1: /*

Since the `VerifyIntrinsicChecks` flag is gone, AFAICT, all following changes can be reverted:


git rm test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java
git checkout upstream/HEAD -- \
test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java \
test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java \
test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java \
test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java

test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 32:

> 30:  *      -XX:CompileCommand=inline,java.lang.StringCoding::*
> 31:  *      -XX:CompileCommand=exclude,jdk.internal.util.Preconditions::checkFromIndexSize
> 32:  *      -XX:CompileCommand=compileonly,compiler.intrinsics.string.TestRangeCheck::test

Is this necessary? (This wasn't used in `TestStringConstruction`.)

test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58:

> 56:             // cut off the dead code. As a result, -1 is fed as input into the
> 57:             // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a
> 58:             // failure in the matcher.

I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ?

Suggestion:

            // Calling `StringCoding::countPositives`, which is a "front door"
            // to the `StringCoding::countPositives0` intrinsic.
            // `countPositives` validates its input using
            // `Preconditions::checkFromIndexSize`, which also maps to an
            // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
            // know about the explicit range checks, and does not cut off the
            // dead code. As a result, an invalid value (e.g., `-1`) can be fed
            // as input into the `countPositives0` intrinsic, got replaced
            // by TOP, and cause a failure in the matcher.

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

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3681112226
PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3738455817
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689568427
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2687948444
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2685859575
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2685838328
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2705884654
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2705885810
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2704760982
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689735070
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689780537

From dfenacci at openjdk.org  Tue Jan 20 18:54:10 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 20 Jan 2026 18:54:10 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
Message-ID: <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>

On Mon, 12 Jan 2026 13:03:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Verified that 3c466d372b7 is a clean revert of 7e18de137c3 delivered in [JDK-8374210].
> 
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Thanks for your review @vy.
In addition to the changes you suggested I also fixed the opaque node value in `LibraryCallKit::generate_limit_guard` which was wrong (I then removed the `is_positive` flag altogether since it was `false` in both cases) and added `TestOpaqueGuardNodes.java` to test that the opaque nodes are added and later removed.

> src/hotspot/share/opto/c2_globals.hpp line 680:
> 
>> 678:   develop(bool, VerifyIntrinsicChecks, false,                               \
>> 679:           "Verify in intrinsic that Java level checks work as expected")    \
>> 680:                                                                             \
> 
> I suggest removing the `VerifyIntrinsicChecks` flag. Given `OpaqueGuard` already verifies the value when `#ifdef ASSERT`, does `VerifyIntrinsicChecks` serve any purpose anymore?

Done.

> src/hotspot/share/opto/loopopts.cpp line 1:
> 
>> 1: /*
> 
> What is the reason that the new `OpaqueGuard` is not taken into account in `PhaseIdealLoop::clone_iff`?

Oversight ? Thanks! Fixed.

> src/hotspot/share/opto/macro.cpp line 2565:
> 
>> 2563:         // Tests with OpaqueGuard nodes are implicitly known to be true or false. Replace the node with appropriate value. In debug builds,
>> 2564:         // we leave the test in the graph to have an additional sanity check at runtime. If the test fails (i.e. a bug),
>> 2565:         // we will execute a Halt node.
> 
> *Nit:* Can we adhere to the max. 120 (or even better, 80!) characters per line limit of the file?

Fair enough (good to know: I wasn't aware of such limit).

> src/hotspot/share/opto/macro.cpp line 2569:
> 
>> 2567:         _igvn.replace_node(n, n->in(1));
>> 2568: #else
>> 2569:         _igvn.replace_node(n, _igvn.intcon(0));
> 
> Curious: why do we invoke `intcon(0)` for `OpaqueGuard`, whereas it was `intcon(1)` for `OpaqueNotNull` slightly above?

In `OpaqueGuard`'s case we know that the input is always "false" (so, we set 0 as its input). For `OpaqueNotNull` we know that the input is always "true" (so, we set 1 as its input).

> src/hotspot/share/opto/opaquenode.hpp line 160:
> 
>> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode
>> 159: // inputs instead).
>> 160: class OpaqueGuardNode : public Node {
> 
> With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of?

It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ?

> test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 1:
> 
>> 1: /*
> 
> Since the `VerifyIntrinsicChecks` flag is gone, AFAICT, all following changes can be reverted:
> 
> 
> git rm test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java
> git checkout upstream/HEAD -- \
> test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java \
> test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java \
> test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java \
> test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java

Totally. Done.

> test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 32:
> 
>> 30:  *      -XX:CompileCommand=inline,java.lang.StringCoding::*
>> 31:  *      -XX:CompileCommand=exclude,jdk.internal.util.Preconditions::checkFromIndexSize
>> 32:  *      -XX:CompileCommand=compileonly,compiler.intrinsics.string.TestRangeCheck::test
> 
> Is this necessary? (This wasn't used in `TestStringConstruction`.)

Nope (leftover from debugging). Removed

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

PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3755585217
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694787876
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694785777
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694785429
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707280040
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707283139
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707272331
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694788432

From vyazici at openjdk.org  Tue Jan 20 18:54:11 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 Jan 2026 18:54:11 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
Message-ID: <DyFi7eM3XWx_t19uqsI95RRb8q40ujL5papopdG1n4k=.679a5d13-3be8-4e9a-bc2e-59392aae9bb9@github.com>

On Tue, 13 Jan 2026 20:01:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> src/hotspot/share/opto/library_call.hpp line 170:
> 
>> 168:                                     Node* length, bool char_count,
>> 169:                                     bool halt_on_oob = false,
>> 170:                                     bool is_opaque = false);
> 
> Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used:
> 
> 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks`
> 2. defaults (i.e., `halt_on_oob=is_opaque=false`)
> 
> Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`?

Giving this a second thought, do we need these two flags anyway? That is,

1. We can remove `if (is_opaque)` add the `OpaqueGuard` anyway, since it is ineffective for `!ASSERT`. (This is what `must_be_not_null` does too.)
2. We can replace `if (halt_on_oob) { ... } else { ... }` with `#ifdef ASSERT ...`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689690430

From dfenacci at openjdk.org  Tue Jan 20 18:54:12 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 20 Jan 2026 18:54:12 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <DyFi7eM3XWx_t19uqsI95RRb8q40ujL5papopdG1n4k=.679a5d13-3be8-4e9a-bc2e-59392aae9bb9@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <DyFi7eM3XWx_t19uqsI95RRb8q40ujL5papopdG1n4k=.679a5d13-3be8-4e9a-bc2e-59392aae9bb9@github.com>
Message-ID: <LWPcI2BXdfYrOXTOJZNvsxG_QpCSk-MY_Vc_LWIe9zg=.a5bdf5b5-0d79-44a1-baca-aed0bfa8eaaf@github.com>

On Wed, 14 Jan 2026 09:38:40 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.hpp line 170:
>> 
>>> 168:                                     Node* length, bool char_count,
>>> 169:                                     bool halt_on_oob = false,
>>> 170:                                     bool is_opaque = false);
>> 
>> Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used:
>> 
>> 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks`
>> 2. defaults (i.e., `halt_on_oob=is_opaque=false`)
>> 
>> Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`?
>
> Giving this a second thought, do we need these two flags anyway? That is,
> 
> 1. We can remove `if (is_opaque)` add the `OpaqueGuard` anyway, since it is ineffective for `!ASSERT`. (This is what `must_be_not_null` does too.)
> 2. We can replace `if (halt_on_oob) { ... } else { ... }` with `#ifdef ASSERT ...`.

1. I'm not sure we can always do that: `LibraryCallKit::generate_string_range_check` is called from places that don't yet have Java range checks and we must not add an opaque node in those cases (or we end up without checks in prod builds).
2. For a similar reason I'd leave `if (halt_on_oob)` condition: for calls to  `LibraryCallKit::generate_string_range_check` that don't yet have Java range checks the method behaves like it did before. For "new" calls it adds the `Halt` node (which will then be removed together with the guard in prod builds).

So, on the one hand we can keep `halt_on_oob` alone as discriminant between "new" and "old" call sites. On the other we can get rid of `VerifyIntrinsicChecks` because we implicitly add the additional range check in debug builds (always). 

I've modified the code accordingly. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694787303

From vyazici at openjdk.org  Tue Jan 20 18:54:12 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 Jan 2026 18:54:12 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>
Message-ID: <sn2GOc4tdoyMYCNjYB4yg9k31OCYDhvJYlugbmN34l8=.d6e02dd6-f8ab-442f-a0f2-ee87bfd4464f@github.com>

On Tue, 20 Jan 2026 08:27:59 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> src/hotspot/share/opto/opaquenode.hpp line 160:
>> 
>>> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode
>>> 159: // inputs instead).
>>> 160: class OpaqueGuardNode : public Node {
>> 
>> With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of?
>
> It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ?

Fair enough ? I was just curious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707418513

From duke at openjdk.org  Tue Jan 20 18:54:14 2026
From: duke at openjdk.org (ExE Boss)
Date: Tue, 20 Jan 2026 18:54:14 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
Message-ID: <osGEnkaCSFQ19GH0FRlPwOrUCB4rlDC8laKd2_LB3w0=.96c5cc4e-e660-4f05-8ddd-096a0769298e@github.com>

On Wed, 14 Jan 2026 10:05:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58:
> 
>> 56:             // cut off the dead code. As a result, -1 is fed as input into the
>> 57:             // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a
>> 58:             // failure in the matcher.
> 
> I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ?
> 
> Suggestion:
> 
>             // Calling `StringCoding::countPositives`, which is a "front door"
>             // to the `StringCoding::countPositives0` intrinsic.
>             // `countPositives` validates its input using
>             // `Preconditions::checkFromIndexSize`, which also maps to an
>             // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
>             // know about the explicit range checks, and does not cut off the
>             // dead code. As a result, an invalid value (e.g., `-1`) can be fed
>             // as input into the `countPositives0` intrinsic, got replaced
>             // by TOP, and cause a failure in the matcher.

**Nit:** Using??get??here is?grammatically?better:

             // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
             // know about the explicit range checks, and does not cut off the
-            // as input into the `countPositives0` intrinsic, got replaced
+            // as input into the `countPositives0` intrinsic, get replaced
             // by TOP, and cause a failure in the matcher.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2690260434

From dfenacci at openjdk.org  Tue Jan 20 18:54:14 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 20 Jan 2026 18:54:14 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <osGEnkaCSFQ19GH0FRlPwOrUCB4rlDC8laKd2_LB3w0=.96c5cc4e-e660-4f05-8ddd-096a0769298e@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <osGEnkaCSFQ19GH0FRlPwOrUCB4rlDC8laKd2_LB3w0=.96c5cc4e-e660-4f05-8ddd-096a0769298e@github.com>
Message-ID: <TPGnDnZFFM1qT-a4tHKrTJFzWf61CUIGgcjlWp2ZtWc=.08cade4c-029e-4f51-af1e-c02d86d7a4c4@github.com>

On Wed, 14 Jan 2026 12:34:51 GMT, ExE Boss <duke at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58:
>> 
>>> 56:             // cut off the dead code. As a result, -1 is fed as input into the
>>> 57:             // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a
>>> 58:             // failure in the matcher.
>> 
>> I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ?
>> 
>> Suggestion:
>> 
>>             // Calling `StringCoding::countPositives`, which is a "front door"
>>             // to the `StringCoding::countPositives0` intrinsic.
>>             // `countPositives` validates its input using
>>             // `Preconditions::checkFromIndexSize`, which also maps to an
>>             // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
>>             // know about the explicit range checks, and does not cut off the
>>             // dead code. As a result, an invalid value (e.g., `-1`) can be fed
>>             // as input into the `countPositives0` intrinsic, got replaced
>>             // by TOP, and cause a failure in the matcher.
>
> **Nit:** Using??get??here is?grammatically?better:
> 
>              // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
>              // know about the explicit range checks, and does not cut off the
> -            // as input into the `countPositives0` intrinsic, got replaced
> +            // as input into the `countPositives0` intrinsic, get replaced
>              // by TOP, and cause a failure in the matcher.

Done. Thanks for the suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694948915

From bpb at openjdk.org  Tue Jan 20 23:24:38 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 Jan 2026 23:24:38 GMT
Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for
 symbolic links in a mapped drive (win) [v3]
In-Reply-To: <n2NDZm9xydm3sgbRuGGE7RLLvTRJU1-_lA9DkRLEuqs=.527acecd-d626-4345-9192-ab37fd7397ac@github.com>
References: <FF548_dJBqnugMihCRQWlNtY5W_BHCSXmX4UqntgZ_c=.5082b69b-e9db-4c28-9603-14f551f09623@github.com>
 <n2NDZm9xydm3sgbRuGGE7RLLvTRJU1-_lA9DkRLEuqs=.527acecd-d626-4345-9192-ab37fd7397ac@github.com>
Message-ID: <mfHz4Ib31-R3aWZRwBGf6-sXkF7lUKBUhKi_3eqtXFg=.21fe41d2-70c5-4f3e-89ae-0806636f1e6e@github.com>

On Wed, 14 Jan 2026 22:27:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> If `getFinalPath` throws an exception, or converts a drive path to a UNC path, then fall back to the slow path which uses `resolveAllLinks`.
>
> 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
>  - 8368165: Improve fallback mechanism when a link cannot be opened for attribute access
>  - 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win)

src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 273:

> 271:                             handle = input.openForReadAttributeAccess(false);
> 272:                             CloseHandle(handle);
> 273:                             handle = INVALID_HANDLE_VALUE;

Lines 272-273 look suspicious. Even if `openForReadAttributeAccess` succeeds at line 271, then `handle` will still be `INVALID_HANDLE_VALUE` and the conditional check in the `if`-block at line 288 will be `false` so `GetFinalPathNameByHandle` will not be called. This logic needs to be reevaluated and retested for the various cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28032#discussion_r2710409869

From bpb at openjdk.org  Thu Jan 22 16:14:21 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jan 2026 16:14:21 GMT
Subject: Integrated: 8367284: (fs) Support current working directory target in
 SecureDirectoryStream.move
In-Reply-To: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
References: <nhut7Z11s0QY-bnxCym7pq7u-dJmU5ISFJSGebyVShc=.712b1208-8e3f-4174-b872-792832d40c37@github.com>
Message-ID: <Q3KDLV7aX-BARiIqS7LMa9Q6EEqyWj3mFuzxMBIhhG8=.a8b1fe82-fcfc-4f58-9906-6aa560d4845a@github.com>

On Tue, 9 Sep 2025 23:04:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `java.nio.file.SecureDirectoryStream.move` so that, instead of throwing a `NullPointerException` if the `targetdir` parameter is `null`, it considers a non-absolute path passed via `targetpath` as being relative to the current working directory.

This pull request has now been integrated.

Changeset: 07f6617e
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07f6617e0b2752b538b6c43250dd0bb65fd8c695
Stats:     44 lines in 3 files changed: 25 ins; 6 del; 13 mod

8367284: (fs) Support current working directory target in SecureDirectoryStream.move

Reviewed-by: alanb

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

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

From vyazici at openjdk.org  Fri Jan 23 13:50:39 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 23 Jan 2026 13:50:39 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <ILLRs0p4F_EwS1Qxnn-VCMaNpOG8qp-S06b8pWzuRfQ=.8ae1f46e-60d2-4747-bafb-96e64270caef@github.com>

On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

I'd like to provide some help for reviewers:

1. [JDK-8361842] (integrated in 655dc516c22) implemented changes for `java.lang.StringCoding`
2. [JDK-8374210] (integrated in 7e18de137c3) reported regressions against JDK-8361842, and used as the BACKOUT issue.
3. [JDK-8374582] (this PR) is the REDO of JDK-8361842, plus the fix for regressions reported in JDK-8374210

That is, this PR starts with 3c466d372b7 (i.e, the revert of 7e18de137c3), and continues with the fix, which is **the interesting part, and that can be viewed by diff'ing 3c466d372b7...ff22857609d**. (ff22857609d is the last commit as of date.)

[JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210
[JDK-8374582]: https://bugs.openjdk.org/browse/JDK-8374582

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

PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3790314570

From dgredler at openjdk.org  Fri Jan 23 18:50:23 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 23 Jan 2026 18:50:23 GMT
Subject: RFR: 8376226: CharsetEncoder.canEncode(CharSequence) is much slower
 than necessary
Message-ID: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>

Subclasses of `CharsetEncoder` often override `canEncode(char)` in order to make it very fast. This is not the case for `canEncode(CharSequence)`, which currently must usually perform the full encoding process. As a result, `canEncode(CharSequence)` is about 20x slower than `canEncode(char)` when the input is encodable, and about 1600x slower than `canEncode(char)` when the input is not encodable.

The reason that performance is even slower for un-encodable input is that the internal logic is relying on a thrown exception to determine that the input cannot be encoded (requiring stack trace setup, etc).

This PR overrides `canEncode(CharSequence)` to simply check `canEncode(char)` on each character in the sequence when the encoding allows this (ASCII, ISO-8859-1, etc). Where this is not possible (e.g. UTF-8, UTF-16) this PR removes the exception-based flow control in `CharsetEncoder` so that the un-encodable scenario is at least improved.

Regression tests run locally:
- `make test TEST="jtreg:test/jdk/java/nio/charset"`
- `make test TEST="jtreg:test/jdk/sun/nio/cs"`

The included benchmark can be run via `make test TEST="micro:java.nio.CharsetCanEncode"`.

JMH benchmark results **before** changes:


Benchmark                                    Mode  Cnt    Score    Error  Units
CharsetCanEncode.asciiCanEncodeCharNo        avgt   30    0.502 ?  0.004  ns/op
CharsetCanEncode.asciiCanEncodeCharYes       avgt   30    0.503 ?  0.003  ns/op
CharsetCanEncode.asciiCanEncodeStringNo      avgt   30  821.635 ?  7.055  ns/op
CharsetCanEncode.asciiCanEncodeStringYes     avgt   30    8.875 ?  0.115  ns/op
CharsetCanEncode.iso88591CanEncodeCharNo     avgt   30    0.508 ?  0.006  ns/op
CharsetCanEncode.iso88591CanEncodeCharYes    avgt   30    0.506 ?  0.004  ns/op
CharsetCanEncode.iso88591CanEncodeStringNo   avgt   30  833.165 ?  7.315  ns/op
CharsetCanEncode.iso88591CanEncodeStringYes  avgt   30   10.357 ?  1.427  ns/op
CharsetCanEncode.iso88592CanEncodeCharNo     avgt   30    0.957 ?  0.009  ns/op
CharsetCanEncode.iso88592CanEncodeCharYes    avgt   30    1.407 ?  0.010  ns/op
CharsetCanEncode.iso88592CanEncodeStringNo   avgt   30  826.478 ?  4.409  ns/op
CharsetCanEncode.iso88592CanEncodeStringYes  avgt   30   13.223 ?  1.479  ns/op
CharsetCanEncode.shiftjisCanEncodeCharNo     avgt   30    1.370 ?  0.012  ns/op
CharsetCanEncode.shiftjisCanEncodeCharYes    avgt   30    1.386 ?  0.010  ns/op
CharsetCanEncode.shiftjisCanEncodeStringNo   avgt   30  850.336 ? 20.107  ns/op
CharsetCanEncode.shiftjisCanEncodeStringYes  avgt   30   10.672 ?  0.088  ns/op
CharsetCanEncode.utf16leCanEncodeCharNo      avgt   30    0.518 ?  0.005  ns/op
CharsetCanEncode.utf16leCanEncodeCharYes     avgt   30    0.517 ?  0.005  ns/op
CharsetCanEncode.utf16leCanEncodeStringNo    avgt   30  857.907 ? 15.492  ns/op
CharsetCanEncode.utf16leCanEncodeStringYes   avgt   30   12.492 ?  1.444  ns/op
CharsetCanEncode.utf8CanEncodeCharNo         avgt   30    0.522 ?  0.008  ns/op
CharsetCanEncode.utf8CanEncodeCharYes        avgt   30    0.518 ?  0.004  ns/op
CharsetCanEncode.utf8CanEncodeStringNo       avgt   30  869.428 ? 11.116  ns/op
CharsetCanEncode.utf8CanEncodeStringYes      avgt   30   19.587 ?  0.190  ns/op


JMH benchmark results **after** changes:


Benchmark                                    Mode  Cnt   Score   Error  Units
CharsetCanEncode.asciiCanEncodeCharNo        avgt   30   0.509 ? 0.004  ns/op
CharsetCanEncode.asciiCanEncodeCharYes       avgt   30   0.504 ? 0.005  ns/op
CharsetCanEncode.asciiCanEncodeStringNo      avgt   30   0.608 ? 0.011  ns/op
CharsetCanEncode.asciiCanEncodeStringYes     avgt   30   0.508 ? 0.006  ns/op
CharsetCanEncode.iso88591CanEncodeCharNo     avgt   30   0.502 ? 0.004  ns/op
CharsetCanEncode.iso88591CanEncodeCharYes    avgt   30   0.502 ? 0.004  ns/op
CharsetCanEncode.iso88591CanEncodeStringNo   avgt   30   0.604 ? 0.004  ns/op
CharsetCanEncode.iso88591CanEncodeStringYes  avgt   30   0.507 ? 0.004  ns/op
CharsetCanEncode.iso88592CanEncodeCharNo     avgt   30   0.952 ? 0.008  ns/op
CharsetCanEncode.iso88592CanEncodeCharYes    avgt   30   1.394 ? 0.009  ns/op
CharsetCanEncode.iso88592CanEncodeStringNo   avgt   30   1.071 ? 0.006  ns/op
CharsetCanEncode.iso88592CanEncodeStringYes  avgt   30   1.375 ? 0.008  ns/op
CharsetCanEncode.shiftjisCanEncodeCharNo     avgt   30   1.360 ? 0.007  ns/op
CharsetCanEncode.shiftjisCanEncodeCharYes    avgt   30   1.381 ? 0.010  ns/op
CharsetCanEncode.shiftjisCanEncodeStringNo   avgt   30   1.581 ? 0.015  ns/op
CharsetCanEncode.shiftjisCanEncodeStringYes  avgt   30   1.388 ? 0.008  ns/op
CharsetCanEncode.utf16leCanEncodeCharNo      avgt   30   0.507 ? 0.004  ns/op
CharsetCanEncode.utf16leCanEncodeCharYes     avgt   30   0.509 ? 0.006  ns/op
CharsetCanEncode.utf16leCanEncodeStringNo    avgt   30  12.177 ? 0.139  ns/op
CharsetCanEncode.utf16leCanEncodeStringYes   avgt   30  10.717 ? 0.098  ns/op
CharsetCanEncode.utf8CanEncodeCharNo         avgt   30   0.511 ? 0.005  ns/op
CharsetCanEncode.utf8CanEncodeCharYes        avgt   30   0.516 ? 0.008  ns/op
CharsetCanEncode.utf8CanEncodeStringNo       avgt   30  24.626 ? 0.226  ns/op
CharsetCanEncode.utf8CanEncodeStringYes      avgt   30  20.593 ? 0.192  ns/op

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

Commit messages:
 - Optimize CharsetEncoder.canEncode(CharSequence)

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

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

From dgredler at openjdk.org  Fri Jan 23 19:00:31 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 23 Jan 2026 19:00:31 GMT
Subject: RFR: 8376226: CharsetEncoder.canEncode(CharSequence) is much
 slower than necessary [v2]
In-Reply-To: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>
References: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>
Message-ID: <pO1BXIpmrhqygikSlslDezL8YaXhJK58ICCAMhYHIAY=.4062c312-ce0a-4c13-bbf8-f9ea4c835486@github.com>

> Subclasses of `CharsetEncoder` often override `canEncode(char)` in order to make it very fast. This is not the case for `canEncode(CharSequence)`, which currently must usually perform the full encoding process. As a result, `canEncode(CharSequence)` is about 20x slower than `canEncode(char)` when the input is encodable, and about 1600x slower than `canEncode(char)` when the input is not encodable.
> 
> The reason that performance is even slower for un-encodable input is that the internal logic is relying on a thrown exception to determine that the input cannot be encoded (requiring stack trace setup, etc).
> 
> This PR overrides `canEncode(CharSequence)` to simply check `canEncode(char)` on each character in the sequence when the encoding allows this (ASCII, ISO-8859-1, etc). Where this is not possible (e.g. UTF-8, UTF-16) this PR removes the exception-based flow control in `CharsetEncoder` so that the un-encodable scenario is at least improved.
> 
> Regression tests run locally:
> - `make test TEST="jtreg:test/jdk/java/nio/charset"`
> - `make test TEST="jtreg:test/jdk/sun/nio/cs"`
> 
> The included benchmark can be run via `make test TEST="micro:java.nio.CharsetCanEncode"`.
> 
> JMH benchmark results **before** changes:
> 
> 
> Benchmark                                    Mode  Cnt    Score    Error  Units
> CharsetCanEncode.asciiCanEncodeCharNo        avgt   30    0.502 ?  0.004  ns/op
> CharsetCanEncode.asciiCanEncodeCharYes       avgt   30    0.503 ?  0.003  ns/op
> CharsetCanEncode.asciiCanEncodeStringNo      avgt   30  821.635 ?  7.055  ns/op
> CharsetCanEncode.asciiCanEncodeStringYes     avgt   30    8.875 ?  0.115  ns/op
> CharsetCanEncode.iso88591CanEncodeCharNo     avgt   30    0.508 ?  0.006  ns/op
> CharsetCanEncode.iso88591CanEncodeCharYes    avgt   30    0.506 ?  0.004  ns/op
> CharsetCanEncode.iso88591CanEncodeStringNo   avgt   30  833.165 ?  7.315  ns/op
> CharsetCanEncode.iso88591CanEncodeStringYes  avgt   30   10.357 ?  1.427  ns/op
> CharsetCanEncode.iso88592CanEncodeCharNo     avgt   30    0.957 ?  0.009  ns/op
> CharsetCanEncode.iso88592CanEncodeCharYes    avgt   30    1.407 ?  0.010  ns/op
> CharsetCanEncode.iso88592CanEncodeStringNo   avgt   30  826.478 ?  4.409  ns/op
> CharsetCanEncode.iso88592CanEncodeStringYes  avgt   30   13.223 ?  1.479  ns/op
> CharsetCanEncode.shiftjisCanEncodeCharNo     avgt   30    1.370 ?  0.012  ns/op
> CharsetCanEncode.shiftjisCanEncodeCharYes    avgt   30    1.386 ?  0.010  ns/op
> CharsetCanEncode.shiftjisCanEncodeStringNo   avgt   30  850.336 ? 20.107  ns/op
> C...

Daniel Gredler has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge master
 - Optimize CharsetEncoder.canEncode(CharSequence)

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

Changes: https://git.openjdk.org/jdk/pull/29391/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29391&range=01
  Stats: 246 lines in 6 files changed: 238 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/29391.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29391/head:pull/29391

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

From alanb at openjdk.org  Sun Jan 25 17:36:56 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Jan 2026 17:36:56 GMT
Subject: RFR: 8376226: CharsetEncoder.canEncode(CharSequence) is much
 slower than necessary [v2]
In-Reply-To: <pO1BXIpmrhqygikSlslDezL8YaXhJK58ICCAMhYHIAY=.4062c312-ce0a-4c13-bbf8-f9ea4c835486@github.com>
References: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>
 <pO1BXIpmrhqygikSlslDezL8YaXhJK58ICCAMhYHIAY=.4062c312-ce0a-4c13-bbf8-f9ea4c835486@github.com>
Message-ID: <66NKdSqLxjUMZ67ur0-seOMqcFD2-MJ4I4ywtXyyDSQ=.fe95f4d8-95fb-4f16-a8cd-a3bfc8284570@github.com>

On Fri, 23 Jan 2026 19:00:31 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Subclasses of `CharsetEncoder` often override `canEncode(char)` in order to make it very fast. This is not the case for `canEncode(CharSequence)`, which currently must usually perform the full encoding process. As a result, `canEncode(CharSequence)` is about 20x slower than `canEncode(char)` when the input is encodable, and about 1600x slower than `canEncode(char)` when the input is not encodable.
>> 
>> The reason that performance is even slower for un-encodable input is that the internal logic is relying on a thrown exception to determine that the input cannot be encoded (requiring stack trace setup, etc).
>> 
>> This PR overrides `canEncode(CharSequence)` to simply check `canEncode(char)` on each character in the sequence when the encoding allows this (ASCII, ISO-8859-1, etc). Where this is not possible (e.g. UTF-8, UTF-16) this PR removes the exception-based flow control in `CharsetEncoder` so that the un-encodable scenario is at least improved.
>> 
>> Regression tests run locally:
>> - `make test TEST="jtreg:test/jdk/java/nio/charset"`
>> - `make test TEST="jtreg:test/jdk/sun/nio/cs"`
>> 
>> The included benchmark can be run via `make test TEST="micro:java.nio.CharsetCanEncode"`.
>> 
>> JMH benchmark results **before** changes:
>> 
>> 
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> CharsetCanEncode.asciiCanEncodeCharNo        avgt   30    0.502 ?  0.004  ns/op
>> CharsetCanEncode.asciiCanEncodeCharYes       avgt   30    0.503 ?  0.003  ns/op
>> CharsetCanEncode.asciiCanEncodeStringNo      avgt   30  821.635 ?  7.055  ns/op
>> CharsetCanEncode.asciiCanEncodeStringYes     avgt   30    8.875 ?  0.115  ns/op
>> CharsetCanEncode.iso88591CanEncodeCharNo     avgt   30    0.508 ?  0.006  ns/op
>> CharsetCanEncode.iso88591CanEncodeCharYes    avgt   30    0.506 ?  0.004  ns/op
>> CharsetCanEncode.iso88591CanEncodeStringNo   avgt   30  833.165 ?  7.315  ns/op
>> CharsetCanEncode.iso88591CanEncodeStringYes  avgt   30   10.357 ?  1.427  ns/op
>> CharsetCanEncode.iso88592CanEncodeCharNo     avgt   30    0.957 ?  0.009  ns/op
>> CharsetCanEncode.iso88592CanEncodeCharYes    avgt   30    1.407 ?  0.010  ns/op
>> CharsetCanEncode.iso88592CanEncodeStringNo   avgt   30  826.478 ?  4.409  ns/op
>> CharsetCanEncode.iso88592CanEncodeStringYes  avgt   30   13.223 ?  1.479  ns/op
>> CharsetCanEncode.shiftjisCanEncodeCharNo     avgt   30    1.370 ?  0.012  ns/op
>> CharsetCanEncode.shiftjisCanEncodeCharYes    avgt   30    1.386 ?  0.010  ns/op
>> CharsetCanEncode.sh...
>
> Daniel Gredler has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - Optimize CharsetEncoder.canEncode(CharSequence)

`canEncode(CharSequence)` in the base classes wraps the String representation. Maybe you've tried this already but can you replace that with the loop over each char so it can be compared with the overrides?

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

PR Comment: https://git.openjdk.org/jdk/pull/29391#issuecomment-3796994065

From jpai at openjdk.org  Mon Jan 26 10:14:24 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 10:14:24 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows
Message-ID: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>

Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 

This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:


java.net.ConnectException: Connection refused: no further information


With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.

A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

Commit messages:
 - add bug id to the test
 - allow NULL for msg in NET_ThrowNew
 - introduce test

Changes: https://git.openjdk.org/jdk/pull/29409/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29409&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376290
  Stats: 157 lines in 4 files changed: 135 ins; 10 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/29409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29409/head:pull/29409

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

From alanb at openjdk.org  Mon Jan 26 10:38:12 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 10:38:12 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>

On Mon, 26 Jan 2026 09:54:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

src/java.base/windows/native/libnet/net_util_md.c line 165:

> 163:             jio_snprintf(fullMsg, sizeof(fullMsg), "%s: %s",
> 164:                              (char *)winsock_errors[i].errString, msg);
> 165:         }

Can you fix up the alignment of the 3rd param, it's a bit messed up with the edits.

test/jdk/java/nio/channels/Selector/FailedConnect.java line 49:

> 47:  * @run junit ${test.main.class}
> 48:  */
> 49: class FailedConnect {

Maybe rename to ConnectionRefusedMessage as this isn't a unit test for connect failing?

test/jdk/java/nio/channels/Selector/FailedConnect.java line 76:

> 74:             System.err.println("establishing connection to " + destAddr);
> 75:             boolean connected = sc.connect(destAddr);
> 76:             assertFalse(connected, "unexpectedly connected to " + destAddr);

I think the test will have to retry if "connected" returns true as it's too easy to have interference between tests on the same host.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727097372
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727105812
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727099761

From jpai at openjdk.org  Mon Jan 26 10:53:11 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 10:53:11 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v2]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <kjHgRIJjl2tXU-I27sBhtKBVTNXftnat1yPv6CA3hEU=.f85f403d-c729-42b7-82a7-198358a39f16@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - rename test to ConnectionRefusedMessage
 - formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/5ce54c2e..8d391779

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

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

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

From jpai at openjdk.org  Mon Jan 26 10:53:15 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 10:53:15 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v2]
In-Reply-To: <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>
Message-ID: <OF_Hm1irvw3dwh5RBcIqt2X_amQzkoOA5VEC94bxwHI=.9690bffb-5311-4703-818a-4853af8c1d26@github.com>

On Mon, 26 Jan 2026 10:32:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - rename test to ConnectionRefusedMessage
>>  - formatting
>
> src/java.base/windows/native/libnet/net_util_md.c line 165:
> 
>> 163:             jio_snprintf(fullMsg, sizeof(fullMsg), "%s: %s",
>> 164:                              (char *)winsock_errors[i].errString, msg);
>> 165:         }
> 
> Can you fix up the alignment of the 3rd param, it's a bit messed up with the edits.

Done - I updated it now to match the formatting in else block. Let me know if this requires any additional formatting change.

> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 76:
> 
>> (failed to retrieve contents of file, check the PR for context)
> I think the test will have to retry if "connected" returns true as it's too easy to have interference between tests on the same host.

Hello Alan, do you mean there could be something that could be listening on these "restricted" ports, after we ensured in `findSuitableRefusedAddress()` that there wasn't anyone listening there?

> test/jdk/java/nio/channels/Selector/FailedConnect.java line 49:
> 
>> 47:  * @run junit ${test.main.class}
>> 48:  */
>> 49: class FailedConnect {
> 
> Maybe rename to ConnectionRefusedMessage as this isn't a unit test for connect failing?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727146106
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727142505
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727142942

From alanb at openjdk.org  Mon Jan 26 10:58:39 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 10:58:39 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v2]
In-Reply-To: <OF_Hm1irvw3dwh5RBcIqt2X_amQzkoOA5VEC94bxwHI=.9690bffb-5311-4703-818a-4853af8c1d26@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>
 <OF_Hm1irvw3dwh5RBcIqt2X_amQzkoOA5VEC94bxwHI=.9690bffb-5311-4703-818a-4853af8c1d26@github.com>
Message-ID: <h_SLapHU9Y3gtLUs7R0AF6caLex4_EjpqjkEBfAHx-I=.99ed6b3f-0ce0-4e2f-bb26-698d94eb4c48@github.com>

On Mon, 26 Jan 2026 10:48:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 76:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> I think the test will have to retry if "connected" returns true as it's too easy to have interference between tests on the same host.
>
> Hello Alan, do you mean there could be something that could be listening on these "restricted" ports, after we ensured in `findSuitableRefusedAddress()` that there wasn't anyone listening there?

Yes, I think I'd prefer if the test skipped if connected or retried.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727164187

From jpai at openjdk.org  Mon Jan 26 12:50:29 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 12:50:29 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

  skip the test if the SocketChannel unexpectedly connects to the destination address

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/8d391779..2e555591

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

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

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

From jpai at openjdk.org  Mon Jan 26 12:50:31 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 12:50:31 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <h_SLapHU9Y3gtLUs7R0AF6caLex4_EjpqjkEBfAHx-I=.99ed6b3f-0ce0-4e2f-bb26-698d94eb4c48@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>
 <OF_Hm1irvw3dwh5RBcIqt2X_amQzkoOA5VEC94bxwHI=.9690bffb-5311-4703-818a-4853af8c1d26@github.com>
 <h_SLapHU9Y3gtLUs7R0AF6caLex4_EjpqjkEBfAHx-I=.99ed6b3f-0ce0-4e2f-bb26-698d94eb4c48@github.com>
Message-ID: <X4dhu_dfdiBTwuL_vf-SBVRpyh8h2QLWlyJ8DFJY3vc=.10f3bf50-0377-4576-8d8f-428241b01208@github.com>

On Mon, 26 Jan 2026 10:55:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hello Alan, do you mean there could be something that could be listening on these "restricted" ports, after we ensured in `findSuitableRefusedAddress()` that there wasn't anyone listening there?
>
> Yes, I think I'd prefer if the test skipped if connected or retried.

Done - I've updated the test to skip it if the SocketChannel connects to the destination address unexpectedly, at any point during the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727483729

From alanb at openjdk.org  Mon Jan 26 13:21:37 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 13:21:37 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
Message-ID: <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>

On Mon, 26 Jan 2026 12:50:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip the test if the SocketChannel unexpectedly connects to the destination address

src/java.base/unix/native/libnet/net_util_md.c line 78:

> 76:             jio_snprintf(fullMsg, sizeof(fullMsg), "socket closed: %s", msg);
> 77:             JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", fullMsg);
> 78:         }

For for this PR but at some point I'd like to know if the EBADF handling is dead code. It shouldn't happen, at least not with the usages in sun.nio.ch/libnio but maybe there is something that I can't think of.

test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 90:

> 88:                         // this test checks the exception message of a ConnectException, so it's
> 89:                         // OK to skip the test if something unexpectedly accepted the connection
> 90:                         throw new TestAbortedException("unexpectedly connected to " + destAddr);

Could this use the assumptions API too? Only asking because we've now got a mix of assumptions API and TestAbortedException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727572402
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727576573

From jpai at openjdk.org  Mon Jan 26 13:34:03 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 13:34:03 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
 <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
Message-ID: <XNXbfpXI1493lm3uvdgFgjDUbi7IbU3hZP4AwamxDZY=.227c0e67-a116-4920-ad57-066d90a2ef82@github.com>

On Mon, 26 Jan 2026 13:18:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip the test if the SocketChannel unexpectedly connects to the destination address
>
> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 90:
> 
>> 88:                         // this test checks the exception message of a ConnectException, so it's
>> 89:                         // OK to skip the test if something unexpectedly accepted the connection
>> 90:                         throw new TestAbortedException("unexpectedly connected to " + destAddr);
> 
> Could this use the assumptions API too? Only asking because we've now got a mix of assumptions API and TestAbortedException.

The reason I used the exception type directly was it looked a bit odd to read something like:


boolean success = sc.finishConnect();
if (success) {
    // this test checks the exception message of a ConnectException, so it's
    // OK to skip the test if something unexpectedly accepted the connection
    assumeTrue(success, "unexpectedly connected to " + destAddr);
}
fail("ConnectException was not thrown");


but I don't have a strong preference here. I'll switch to using the `Assumptions.assumeXXX` API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727616602

From jpai at openjdk.org  Mon Jan 26 14:03:16 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 14:03:16 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v4]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <MTlbO1-MgJv5l-of7IqLr-oBKa-AuAIOzOlwPwhOz7U=.ca7b26c0-118f-4701-82d2-9463ed51f1c2@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

  replace TestAbortedException with Assumptions.assumeTrue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/2e555591..c184f07a

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

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

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

From jpai at openjdk.org  Mon Jan 26 14:03:20 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 14:03:20 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
 <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
Message-ID: <mbl94wBSL4q17y0j1bELqvFOpoXVoIx7Glw7L-bm3tg=.570923a3-3579-4c00-bb3b-ec51787b6594@github.com>

On Mon, 26 Jan 2026 13:17:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip the test if the SocketChannel unexpectedly connects to the destination address
>
> src/java.base/unix/native/libnet/net_util_md.c line 78:
> 
>> 76:             jio_snprintf(fullMsg, sizeof(fullMsg), "socket closed: %s", msg);
>> 77:             JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", fullMsg);
>> 78:         }
> 
> For for this PR but at some point I'd like to know if the EBADF handling is dead code. It shouldn't happen, at least not with the usages in sun.nio.ch/libnio but maybe there is something that I can't think of.

I've added it to my TODO list and will file a JBS issue after investigating a bit more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727723238

From jpai at openjdk.org  Mon Jan 26 14:03:23 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 14:03:23 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <XNXbfpXI1493lm3uvdgFgjDUbi7IbU3hZP4AwamxDZY=.227c0e67-a116-4920-ad57-066d90a2ef82@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
 <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
 <XNXbfpXI1493lm3uvdgFgjDUbi7IbU3hZP4AwamxDZY=.227c0e67-a116-4920-ad57-066d90a2ef82@github.com>
Message-ID: <mwv39ZxtAhfhdfup9UqCk_M14H4pltChUFqEobRllnU=.65ea9078-bea0-4459-bb60-c10f208313ae@github.com>

On Mon, 26 Jan 2026 13:31:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 90:
>> 
>>> 88:                         // this test checks the exception message of a ConnectException, so it's
>>> 89:                         // OK to skip the test if something unexpectedly accepted the connection
>>> 90:                         throw new TestAbortedException("unexpectedly connected to " + destAddr);
>> 
>> Could this use the assumptions API too? Only asking because we've now got a mix of assumptions API and TestAbortedException.
>
> The reason I used the exception type directly was it looked a bit odd to read something like:
> 
> 
> boolean success = sc.finishConnect();
> if (success) {
>     // this test checks the exception message of a ConnectException, so it's
>     // OK to skip the test if something unexpectedly accepted the connection
>     assumeTrue(success, "unexpectedly connected to " + destAddr);
> }
> fail("ConnectException was not thrown");
> 
> 
> but I don't have a strong preference here. I'll switch to using the `Assumptions.assumeXXX` API.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727720793

From dgredler at openjdk.org  Mon Jan 26 15:02:14 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 26 Jan 2026 15:02:14 GMT
Subject: RFR: 8376226: CharsetEncoder.canEncode(CharSequence) is much
 slower than necessary [v2]
In-Reply-To: <66NKdSqLxjUMZ67ur0-seOMqcFD2-MJ4I4ywtXyyDSQ=.fe95f4d8-95fb-4f16-a8cd-a3bfc8284570@github.com>
References: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>
 <pO1BXIpmrhqygikSlslDezL8YaXhJK58ICCAMhYHIAY=.4062c312-ce0a-4c13-bbf8-f9ea4c835486@github.com>
 <66NKdSqLxjUMZ67ur0-seOMqcFD2-MJ4I4ywtXyyDSQ=.fe95f4d8-95fb-4f16-a8cd-a3bfc8284570@github.com>
Message-ID: <Xor7DJmMB95DWQiVYY1EnCB8dM6kKLvL_Nr1ji6agz0=.2acabdc0-2364-4033-9dd7-51fb018658b1@github.com>

On Sun, 25 Jan 2026 17:34:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge master
>>  - Optimize CharsetEncoder.canEncode(CharSequence)
>
> `canEncode(CharSequence)` in the base classes wraps the String representation. Maybe you've tried this already but can you replace that with the loop over each char so it can be compared with the overrides?

@AlanBateman A simple char loop in the base `CharsetEncoder` class would be incorrect for encodings like UTF-8 and UTF-16, no? (since they have surrogate pairs which may not encode correctly in isolation) I think the current behavior (slow, but guaranteed to work if actual encoding works) is good as a baseline fallback.

The `EUC_TW` encoder is currently the only class which overrides `canEncode(CharSequence)`, and it has to deal with surrogates. I can update `canEncode` in `UTF_8` and `UnicodeEncoder` (which handles UTF-16 variants) if you'd like, but I had initially tried to focus on the simpler cases (no surrogate pairs). Just let me know.

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

PR Comment: https://git.openjdk.org/jdk/pull/29391#issuecomment-3800030312

From alanb at openjdk.org  Mon Jan 26 16:42:22 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 16:42:22 GMT
Subject: RFR: 8376226: CharsetEncoder.canEncode(CharSequence) is much
 slower than necessary [v2]
In-Reply-To: <pO1BXIpmrhqygikSlslDezL8YaXhJK58ICCAMhYHIAY=.4062c312-ce0a-4c13-bbf8-f9ea4c835486@github.com>
References: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>
 <pO1BXIpmrhqygikSlslDezL8YaXhJK58ICCAMhYHIAY=.4062c312-ce0a-4c13-bbf8-f9ea4c835486@github.com>
Message-ID: <5QJCaAJK_gM3TjyZhdcoMYvRTNXadEV3QVPM405OmbM=.543db8b1-60ac-48f9-8e88-e566ef3dbe31@github.com>

On Fri, 23 Jan 2026 19:00:31 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Subclasses of `CharsetEncoder` often override `canEncode(char)` in order to make it very fast. This is not the case for `canEncode(CharSequence)`, which currently must usually perform the full encoding process. As a result, `canEncode(CharSequence)` is about 20x slower than `canEncode(char)` when the input is encodable, and about 1600x slower than `canEncode(char)` when the input is not encodable.
>> 
>> The reason that performance is even slower for un-encodable input is that the internal logic is relying on a thrown exception to determine that the input cannot be encoded (requiring stack trace setup, etc).
>> 
>> This PR overrides `canEncode(CharSequence)` to simply check `canEncode(char)` on each character in the sequence when the encoding allows this (ASCII, ISO-8859-1, etc). Where this is not possible (e.g. UTF-8, UTF-16) this PR removes the exception-based flow control in `CharsetEncoder` so that the un-encodable scenario is at least improved.
>> 
>> Regression tests run locally:
>> - `make test TEST="jtreg:test/jdk/java/nio/charset"`
>> - `make test TEST="jtreg:test/jdk/sun/nio/cs"`
>> 
>> The included benchmark can be run via `make test TEST="micro:java.nio.CharsetCanEncode"`.
>> 
>> JMH benchmark results **before** changes:
>> 
>> 
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> CharsetCanEncode.asciiCanEncodeCharNo        avgt   30    0.502 ?  0.004  ns/op
>> CharsetCanEncode.asciiCanEncodeCharYes       avgt   30    0.503 ?  0.003  ns/op
>> CharsetCanEncode.asciiCanEncodeStringNo      avgt   30  821.635 ?  7.055  ns/op
>> CharsetCanEncode.asciiCanEncodeStringYes     avgt   30    8.875 ?  0.115  ns/op
>> CharsetCanEncode.iso88591CanEncodeCharNo     avgt   30    0.508 ?  0.006  ns/op
>> CharsetCanEncode.iso88591CanEncodeCharYes    avgt   30    0.506 ?  0.004  ns/op
>> CharsetCanEncode.iso88591CanEncodeStringNo   avgt   30  833.165 ?  7.315  ns/op
>> CharsetCanEncode.iso88591CanEncodeStringYes  avgt   30   10.357 ?  1.427  ns/op
>> CharsetCanEncode.iso88592CanEncodeCharNo     avgt   30    0.957 ?  0.009  ns/op
>> CharsetCanEncode.iso88592CanEncodeCharYes    avgt   30    1.407 ?  0.010  ns/op
>> CharsetCanEncode.iso88592CanEncodeStringNo   avgt   30  826.478 ?  4.409  ns/op
>> CharsetCanEncode.iso88592CanEncodeStringYes  avgt   30   13.223 ?  1.479  ns/op
>> CharsetCanEncode.shiftjisCanEncodeCharNo     avgt   30    1.370 ?  0.012  ns/op
>> CharsetCanEncode.shiftjisCanEncodeCharYes    avgt   30    1.386 ?  0.010  ns/op
>> CharsetCanEncode.sh...
>
> Daniel Gredler has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - Optimize CharsetEncoder.canEncode(CharSequence)

Okay, let's go with what you have. src changes are fine, only skimmed (not detailed review) of the benchmark.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29391#pullrequestreview-3706923124

From naoto at openjdk.org  Mon Jan 26 18:23:36 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jan 2026 18:23:36 GMT
Subject: RFR: 8376226: CharsetEncoder.canEncode(CharSequence) is much
 slower than necessary [v2]
In-Reply-To: <pO1BXIpmrhqygikSlslDezL8YaXhJK58ICCAMhYHIAY=.4062c312-ce0a-4c13-bbf8-f9ea4c835486@github.com>
References: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>
 <pO1BXIpmrhqygikSlslDezL8YaXhJK58ICCAMhYHIAY=.4062c312-ce0a-4c13-bbf8-f9ea4c835486@github.com>
Message-ID: <Y9QfWzxJyCOMC2DZtv5iBJE7A-YrFD5KC-Z8tVCG568=.a71f3c72-6d17-4020-bd45-bcbc0dda6975@github.com>

On Fri, 23 Jan 2026 19:00:31 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Subclasses of `CharsetEncoder` often override `canEncode(char)` in order to make it very fast. This is not the case for `canEncode(CharSequence)`, which currently must usually perform the full encoding process. As a result, `canEncode(CharSequence)` is about 20x slower than `canEncode(char)` when the input is encodable, and about 1600x slower than `canEncode(char)` when the input is not encodable.
>> 
>> The reason that performance is even slower for un-encodable input is that the internal logic is relying on a thrown exception to determine that the input cannot be encoded (requiring stack trace setup, etc).
>> 
>> This PR overrides `canEncode(CharSequence)` to simply check `canEncode(char)` on each character in the sequence when the encoding allows this (ASCII, ISO-8859-1, etc). Where this is not possible (e.g. UTF-8, UTF-16) this PR removes the exception-based flow control in `CharsetEncoder` so that the un-encodable scenario is at least improved.
>> 
>> Regression tests run locally:
>> - `make test TEST="jtreg:test/jdk/java/nio/charset"`
>> - `make test TEST="jtreg:test/jdk/sun/nio/cs"`
>> 
>> The included benchmark can be run via `make test TEST="micro:java.nio.CharsetCanEncode"`.
>> 
>> JMH benchmark results **before** changes:
>> 
>> 
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> CharsetCanEncode.asciiCanEncodeCharNo        avgt   30    0.502 ?  0.004  ns/op
>> CharsetCanEncode.asciiCanEncodeCharYes       avgt   30    0.503 ?  0.003  ns/op
>> CharsetCanEncode.asciiCanEncodeStringNo      avgt   30  821.635 ?  7.055  ns/op
>> CharsetCanEncode.asciiCanEncodeStringYes     avgt   30    8.875 ?  0.115  ns/op
>> CharsetCanEncode.iso88591CanEncodeCharNo     avgt   30    0.508 ?  0.006  ns/op
>> CharsetCanEncode.iso88591CanEncodeCharYes    avgt   30    0.506 ?  0.004  ns/op
>> CharsetCanEncode.iso88591CanEncodeStringNo   avgt   30  833.165 ?  7.315  ns/op
>> CharsetCanEncode.iso88591CanEncodeStringYes  avgt   30   10.357 ?  1.427  ns/op
>> CharsetCanEncode.iso88592CanEncodeCharNo     avgt   30    0.957 ?  0.009  ns/op
>> CharsetCanEncode.iso88592CanEncodeCharYes    avgt   30    1.407 ?  0.010  ns/op
>> CharsetCanEncode.iso88592CanEncodeStringNo   avgt   30  826.478 ?  4.409  ns/op
>> CharsetCanEncode.iso88592CanEncodeStringYes  avgt   30   13.223 ?  1.479  ns/op
>> CharsetCanEncode.shiftjisCanEncodeCharNo     avgt   30    1.370 ?  0.012  ns/op
>> CharsetCanEncode.shiftjisCanEncodeCharYes    avgt   30    1.386 ?  0.010  ns/op
>> CharsetCanEncode.sh...
>
> Daniel Gredler has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - Optimize CharsetEncoder.canEncode(CharSequence)

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29391#pullrequestreview-3707373826

From sgrinovero at openjdk.org  Mon Jan 26 19:18:51 2026
From: sgrinovero at openjdk.org (Sanne Grinovero)
Date: Mon, 26 Jan 2026 19:18:51 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <ZrflRNaVtM7HrbFuwjXh8ngJMn00zD2jKkByPMdIZeY=.f0693f47-50cc-4b13-b12f-6c7e883b9676@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
 <vUzMYmZn2xE6ZnFoz_IITXfZ5MbV3kg_ELDnECAIQQo=.c1229f3a-fa3b-46f2-8ca4-06e09cd34a50@github.com>
 <ZrflRNaVtM7HrbFuwjXh8ngJMn00zD2jKkByPMdIZeY=.f0693f47-50cc-4b13-b12f-6c7e883b9676@github.com>
Message-ID: <V5nj0aOBLTtiARd5RlPjTBs2PtZGgamAeNoJUpVYkHo=.c0bb1159-08db-4cdc-9a4b-31485757d748@github.com>

On Wed, 4 Dec 2024 19:29:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/ThreadPool.java line 76:
>> 
>>> 74:             t.setDaemon(true);
>>> 75:             return t;
>>> 76:         };
>> 
>> This is another case where we should move to InnocuousThread, not this PR of course.
>
> Tracked by [JDK-8345432](https://bugs.openjdk.org/browse/JDK-8345432).

Hello - a bit late, but I was trying to find the rationale.  It's a subtle change but it has implications and is breaking some libraries.
It's no big deal and we can deal with it, for example: https://github.com/quarkusio/quarkus/issues/52134#issuecomment-3789173826

But I'd like to check if this was really the intent?  Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r2720559797

From sgrinovero at openjdk.org  Mon Jan 26 19:18:52 2026
From: sgrinovero at openjdk.org (Sanne Grinovero)
Date: Mon, 26 Jan 2026 19:18:52 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <V5nj0aOBLTtiARd5RlPjTBs2PtZGgamAeNoJUpVYkHo=.c0bb1159-08db-4cdc-9a4b-31485757d748@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
 <vUzMYmZn2xE6ZnFoz_IITXfZ5MbV3kg_ELDnECAIQQo=.c1229f3a-fa3b-46f2-8ca4-06e09cd34a50@github.com>
 <ZrflRNaVtM7HrbFuwjXh8ngJMn00zD2jKkByPMdIZeY=.f0693f47-50cc-4b13-b12f-6c7e883b9676@github.com>
 <V5nj0aOBLTtiARd5RlPjTBs2PtZGgamAeNoJUpVYkHo=.c0bb1159-08db-4cdc-9a4b-31485757d748@github.com>
Message-ID: <SyWi2I7hkvRkMzPGkyJFf5F2VUEZN2HZokxxRB9p0NA=.c9b00ec1-8fa0-4d2c-8f41-a160ecbb3c57@github.com>

On Fri, 23 Jan 2026 10:07:13 GMT, Sanne Grinovero <sgrinovero at openjdk.org> wrote:

>> Tracked by [JDK-8345432](https://bugs.openjdk.org/browse/JDK-8345432).
>
> Hello - a bit late, but I was trying to find the rationale.  It's a subtle change but it has implications and is breaking some libraries.
> It's no big deal and we can deal with it, for example: https://github.com/quarkusio/quarkus/issues/52134#issuecomment-3789173826
> 
> But I'd like to check if this was really the intent?  Thanks!

Ok I've now found https://bugs.openjdk.org/browse/JDK-8348591 - I understand the intent and that this was indeed intentional now.
Still, please be aware that several libraries were relying on the previous semantics of carrying the TCCL across.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r2720587598

From alanb at openjdk.org  Mon Jan 26 19:37:12 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 19:37:12 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v4]
In-Reply-To: <MTlbO1-MgJv5l-of7IqLr-oBKa-AuAIOzOlwPwhOz7U=.ca7b26c0-118f-4701-82d2-9463ed51f1c2@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <MTlbO1-MgJv5l-of7IqLr-oBKa-AuAIOzOlwPwhOz7U=.ca7b26c0-118f-4701-82d2-9463ed51f1c2@github.com>
Message-ID: <BTioWK4SuepADZCM28obMAYpVrMmFrhYmMl9AioYURs=.32d6b576-be68-4796-9cc9-7a875abc7c32@github.com>

On Mon, 26 Jan 2026 14:03:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace TestAbortedException with Assumptions.assumeTrue

Marked as reviewed by alanb (Reviewer).

test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 91:

> 89:                         assumeTrue(success, "unexpectedly connected to " + destAddr);
> 90:                     }
> 91:                     fail("ConnectException was not thrown");

The test is fine, I'm just curious why the assumeTrue is predicated on success being true, is this left over from the previous iteration? If it is removed then the fail goes away too.

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

PR Review: https://git.openjdk.org/jdk/pull/29409#pullrequestreview-3707652821
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2728960365

From bpb at openjdk.org  Mon Jan 26 23:11:32 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Jan 2026 23:11:32 GMT
Subject: RFR: 8376419: (fs) Minor improvement of
 java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
Message-ID: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>

1. Use `RandomFactory` instead of `new Random` to allow reproducibility.
2. Use `jtreg.SkippedException` instead of printing a message and returning silently.

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

Commit messages:
 - 8376419: (fs) Minor improvement of java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java

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

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

From jpai at openjdk.org  Tue Jan 27 07:42:19 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 07:42:19 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v5]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

 - merge latest from master branch
 - fix assumption in test
 - merge latest from master branch
 - replace TestAbortedException with Assumptions.assumeTrue
 - skip the test if the SocketChannel unexpectedly connects to the destination address
 - rename test to ConnectionRefusedMessage
 - formatting
 - add bug id to the test
 - allow NULL for msg in NET_ThrowNew
 - introduce test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/c184f07a..b57b088e

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

  Stats: 3279 lines in 133 files changed: 1600 ins; 833 del; 846 mod
  Patch: https://git.openjdk.org/jdk/pull/29409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29409/head:pull/29409

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

From jpai at openjdk.org  Tue Jan 27 07:42:21 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 07:42:21 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v4]
In-Reply-To: <BTioWK4SuepADZCM28obMAYpVrMmFrhYmMl9AioYURs=.32d6b576-be68-4796-9cc9-7a875abc7c32@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <MTlbO1-MgJv5l-of7IqLr-oBKa-AuAIOzOlwPwhOz7U=.ca7b26c0-118f-4701-82d2-9463ed51f1c2@github.com>
 <BTioWK4SuepADZCM28obMAYpVrMmFrhYmMl9AioYURs=.32d6b576-be68-4796-9cc9-7a875abc7c32@github.com>
Message-ID: <-hza3ECeKacPnF61JzqFczwINXQzF_m3qPcrEeQOvKo=.43548ae0-d65d-462c-8400-288154d7716e@github.com>

On Mon, 26 Jan 2026 19:33:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace TestAbortedException with Assumptions.assumeTrue
>
> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 91:
> 
>> 89:                         assumeTrue(success, "unexpectedly connected to " + destAddr);
>> 90:                     }
>> 91:                     fail("ConnectException was not thrown");
> 
> The test is fine, I'm just curious why the assumeTrue is predicated on success being true, is this left over from the previous iteration? If it is removed then the fail goes away too.

Hello Alan, I got that assumeTrue call wrong in that previous update. What I really wanted there was to skip the test if finishConnect() returned true (i.e. if something unexpectedly accepted the connection). The test doesn't expect finishConnect() to complete normally with a return value of false, and if that happens then I wanted to fail the test. I've now updated the PR accordingly. Does this look reasonable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2730647640

From jpai at openjdk.org  Tue Jan 27 08:03:03 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 08:03:03 GMT
Subject: RFR: 8376419: (fs) Minor improvement of
 java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
In-Reply-To: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
References: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
Message-ID: <ppGqiwC3yZwIFMP0e8OPFpZniIsAi3UJTYnxulzQmCw=.b2976867-bdc0-4345-b85c-5e52fb55544c@github.com>

On Mon, 26 Jan 2026 23:03:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> 1. Use `RandomFactory` instead of `new Random` to allow reproducibility.
> 2. Use `jtreg.SkippedException` instead of printing a message and returning silently.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29434#pullrequestreview-3709648567

From chagedorn at openjdk.org  Tue Jan 27 09:33:02 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 27 Jan 2026 09:33:02 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <Pz0pq_L2Pa3Bq9RWksAGkPCT7_Tk0kWNm_MSZCUMQ_s=.c2f9c052-ab37-4a43-a217-a89fea80dd10@github.com>

On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Overall, the fix idea with `Opaque` nodes looks good to me!

src/hotspot/share/opto/library_call.hpp line 161:

> 159:   Node* generate_negative_guard(Node* index, RegionNode* region,
> 160:                                 // resulting CastII of index:
> 161:                                 Node* *pos_index = nullptr,

Suggestion:

                                Node** pos_index = nullptr,

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

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3710064929
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2731064422

From chagedorn at openjdk.org  Tue Jan 27 09:33:03 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 27 Jan 2026 09:33:03 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <sn2GOc4tdoyMYCNjYB4yg9k31OCYDhvJYlugbmN34l8=.d6e02dd6-f8ab-442f-a0f2-ee87bfd4464f@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>
 <sn2GOc4tdoyMYCNjYB4yg9k31OCYDhvJYlugbmN34l8=.d6e02dd6-f8ab-442f-a0f2-ee87bfd4464f@github.com>
Message-ID: <p_72oa29MDb8NTKDxNtYxINXAqP6uItH0uUL4NJLsCM=.274c3609-b2a0-4dac-8b72-4e1ba881fc01@github.com>

On Tue, 20 Jan 2026 09:06:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ?
>
> Fair enough ? I was just curious.

I was about to ask the same question. It seems like both `OpaqueNotNullNode` and `OpaqueGuardNode` behave the same apart from eventually folding to a false or true constant. They might have slightly different reasons for adding them but AFAIU, they are both intended to keep control and data in sync. Apart from duplicating most of the logic and comments, an additional challenge with having both nodes is that we need to special case both nodes at various points in the code which makes it more complex and raises the question if we could really observe them both or not (would not be a problem when only having one node type).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2731057975

From msheppar at openjdk.org  Tue Jan 27 12:03:19 2026
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 27 Jan 2026 12:03:19 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v5]
In-Reply-To: <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>
Message-ID: <GeQRZMc97BESTvztKeNPh-tdkL-Towl-xn9eqXsgHKo=.58a36ff6-0079-4103-81ad-2d48f1369338@github.com>

On Tue, 27 Jan 2026 07:42:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - merge latest from master branch
>  - fix assumption in test
>  - merge latest from master branch
>  - replace TestAbortedException with Assumptions.assumeTrue
>  - skip the test if the SocketChannel unexpectedly connects to the destination address
>  - rename test to ConnectionRefusedMessage
>  - formatting
>  - add bug id to the test
>  - allow NULL for msg in NET_ThrowNew
>  - introduce test

test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 108:

> 106:         final InetAddress loopbackAddr = InetAddress.getLoopbackAddress();
> 107:         // port 47 is reserved - there should be nothing listening on it
> 108:         InetSocketAddress destAddr = new InetSocketAddress(loopbackAddr, 47);

a general comment on the dest port selections below, 47, 51, 61.
These are currently marked as reserved in the IANA port list, but if you look at the /etc/services file, on macos, you will see that there is a legacy assignment

As such, a comment in the test would be useful, such as,

// using ports 47, 51, 61 from the the IANA reserved port list, which
// are currently unassigned, on the assumption they will not used by
// a listening service

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2731678262

From dgredler at openjdk.org  Tue Jan 27 13:23:50 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 27 Jan 2026 13:23:50 GMT
Subject: Integrated: 8376226: CharsetEncoder.canEncode(CharSequence) is much
 slower than necessary
In-Reply-To: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>
References: <MOM7licEKPyqjI9bde9Gvx-ChPC82XwMivtrJAIRML0=.498e15d1-92c0-4ec8-a03c-49a5fe9e51de@github.com>
Message-ID: <94GDx91f792O1twvy1wfMDrVFuq7xxYjPdXt0Xntcro=.373bd771-81b2-4b28-a264-d08b8e888f83@github.com>

On Fri, 23 Jan 2026 18:41:37 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Subclasses of `CharsetEncoder` often override `canEncode(char)` in order to make it very fast. This is not the case for `canEncode(CharSequence)`, which currently must usually perform the full encoding process. As a result, `canEncode(CharSequence)` is about 20x slower than `canEncode(char)` when the input is encodable, and about 1600x slower than `canEncode(char)` when the input is not encodable.
> 
> The reason that performance is even slower for un-encodable input is that the internal logic is relying on a thrown exception to determine that the input cannot be encoded (requiring stack trace setup, etc).
> 
> This PR overrides `canEncode(CharSequence)` to simply check `canEncode(char)` on each character in the sequence when the encoding allows this (ASCII, ISO-8859-1, etc). Where this is not possible (e.g. UTF-8, UTF-16) this PR removes the exception-based flow control in `CharsetEncoder` so that the un-encodable scenario is at least improved.
> 
> Regression tests run locally:
> - `make test TEST="jtreg:test/jdk/java/nio/charset"`
> - `make test TEST="jtreg:test/jdk/sun/nio/cs"`
> 
> The included benchmark can be run via `make test TEST="micro:java.nio.CharsetCanEncode"`.
> 
> JMH benchmark results **before** changes:
> 
> 
> Benchmark                                    Mode  Cnt    Score    Error  Units
> CharsetCanEncode.asciiCanEncodeCharNo        avgt   30    0.502 ?  0.004  ns/op
> CharsetCanEncode.asciiCanEncodeCharYes       avgt   30    0.503 ?  0.003  ns/op
> CharsetCanEncode.asciiCanEncodeStringNo      avgt   30  821.635 ?  7.055  ns/op
> CharsetCanEncode.asciiCanEncodeStringYes     avgt   30    8.875 ?  0.115  ns/op
> CharsetCanEncode.iso88591CanEncodeCharNo     avgt   30    0.508 ?  0.006  ns/op
> CharsetCanEncode.iso88591CanEncodeCharYes    avgt   30    0.506 ?  0.004  ns/op
> CharsetCanEncode.iso88591CanEncodeStringNo   avgt   30  833.165 ?  7.315  ns/op
> CharsetCanEncode.iso88591CanEncodeStringYes  avgt   30   10.357 ?  1.427  ns/op
> CharsetCanEncode.iso88592CanEncodeCharNo     avgt   30    0.957 ?  0.009  ns/op
> CharsetCanEncode.iso88592CanEncodeCharYes    avgt   30    1.407 ?  0.010  ns/op
> CharsetCanEncode.iso88592CanEncodeStringNo   avgt   30  826.478 ?  4.409  ns/op
> CharsetCanEncode.iso88592CanEncodeStringYes  avgt   30   13.223 ?  1.479  ns/op
> CharsetCanEncode.shiftjisCanEncodeCharNo     avgt   30    1.370 ?  0.012  ns/op
> CharsetCanEncode.shiftjisCanEncodeCharYes    avgt   30    1.386 ?  0.010  ns/op
> CharsetCanEncode.shiftjisCanEncodeStringNo   avgt   30  850.336 ? 20.107  ns/op
> C...

This pull request has now been integrated.

Changeset: 992a8ef4
Author:    Daniel Gredler <dgredler at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/992a8ef46bc0a06c70fd5f4f307dbd20e402ed33
Stats:     246 lines in 6 files changed: 238 ins; 1 del; 7 mod

8376226: CharsetEncoder.canEncode(CharSequence) is much slower than necessary

Reviewed-by: alanb, naoto

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

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

From jpai at openjdk.org  Tue Jan 27 15:55:11 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 15:55:11 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v6]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

  update code comment in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/b57b088e..2ad911f9

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

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

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

From jpai at openjdk.org  Tue Jan 27 15:55:16 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 15:55:16 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v5]
In-Reply-To: <GeQRZMc97BESTvztKeNPh-tdkL-Towl-xn9eqXsgHKo=.58a36ff6-0079-4103-81ad-2d48f1369338@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>
 <GeQRZMc97BESTvztKeNPh-tdkL-Towl-xn9eqXsgHKo=.58a36ff6-0079-4103-81ad-2d48f1369338@github.com>
Message-ID: <q3OR1IYg-kwz4tv_Kcn7-9nT1a7uPcGb17bqBnK_kic=.e0a09b00-1995-451a-b3ac-e4517d7a8ec5@github.com>

On Tue, 27 Jan 2026 12:00:44 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - merge latest from master branch
>>  - fix assumption in test
>>  - merge latest from master branch
>>  - replace TestAbortedException with Assumptions.assumeTrue
>>  - skip the test if the SocketChannel unexpectedly connects to the destination address
>>  - rename test to ConnectionRefusedMessage
>>  - formatting
>>  - add bug id to the test
>>  - allow NULL for msg in NET_ThrowNew
>>  - introduce test
>
> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 108:
> 
>> 106:         final InetAddress loopbackAddr = InetAddress.getLoopbackAddress();
>> 107:         // port 47 is reserved - there should be nothing listening on it
>> 108:         InetSocketAddress destAddr = new InetSocketAddress(loopbackAddr, 47);
> 
> a general comment on the dest port selections below, 47, 51, 61.
> These are currently marked as reserved in the IANA port list, but if you look at the /etc/services file, on macos, you will see that there is a legacy assignment
> 
> As such, a comment in the test would be useful, such as,
> 
> // using ports 47, 51, 61 from the the IANA reserved port list, which
> // are currently unassigned, on the assumption they will not used by
> // a listening service

Done, I've used your suggestion and updated that comment to be more descriptive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2732676508

From dfenacci at openjdk.org  Tue Jan 27 16:22:52 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 27 Jan 2026 16:22:52 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v2]
In-Reply-To: <p_72oa29MDb8NTKDxNtYxINXAqP6uItH0uUL4NJLsCM=.274c3609-b2a0-4dac-8b72-4e1ba881fc01@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>
 <sn2GOc4tdoyMYCNjYB4yg9k31OCYDhvJYlugbmN34l8=.d6e02dd6-f8ab-442f-a0f2-ee87bfd4464f@github.com>
 <p_72oa29MDb8NTKDxNtYxINXAqP6uItH0uUL4NJLsCM=.274c3609-b2a0-4dac-8b72-4e1ba881fc01@github.com>
Message-ID: <Ol4UunnyjJ2breqdwRf2AO5chwcD88rAMMjRf07s47U=.45feee45-a7e5-4798-a77e-1aa7ce039ac1@github.com>

On Tue, 27 Jan 2026 09:24:34 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Fair enough ? I was just curious.
>
> I was about to ask the same question. It seems like both `OpaqueNotNullNode` and `OpaqueGuardNode` behave the same apart from eventually folding to a false or true constant. They might have slightly different reasons for adding them but AFAIU, they are both intended to keep control and data in sync. Apart from duplicating most of the logic and comments, an additional challenge with having both nodes is that we need to special case both nodes at various points in the code which makes it more complex and raises the question if we could really observe them both or not (would not be a problem when only having one node type).

Thanks for reviewing @chhagedorn.

> special case both nodes at various points

Good point. I guess better have only one after all. Changed. (I called it `OpaqueCheck` for lack of a better idea)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2732811990

From dfenacci at openjdk.org  Tue Jan 27 16:22:52 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 27 Jan 2026 16:22:52 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v2]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <Oq2vN6wGYB6q2wbKB2oNqwXhOR2FeypoT_G5qq07AX0=.818ff2d9-6a4e-4b53-882b-6fd0c00721c4@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:

 - JDK-8374852: fix macro expansion for OpaqueCheck
 - JDK-8374852: use only one opaque node

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/ff228576..b79738c3

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

  Stats: 95 lines in 15 files changed: 11 ins; 42 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

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

From msheppar at openjdk.org  Tue Jan 27 16:24:38 2026
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 27 Jan 2026 16:24:38 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v5]
In-Reply-To: <q3OR1IYg-kwz4tv_Kcn7-9nT1a7uPcGb17bqBnK_kic=.e0a09b00-1995-451a-b3ac-e4517d7a8ec5@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>
 <GeQRZMc97BESTvztKeNPh-tdkL-Towl-xn9eqXsgHKo=.58a36ff6-0079-4103-81ad-2d48f1369338@github.com>
 <q3OR1IYg-kwz4tv_Kcn7-9nT1a7uPcGb17bqBnK_kic=.e0a09b00-1995-451a-b3ac-e4517d7a8ec5@github.com>
Message-ID: <NAiCOiATtX7bKN0ySbnh0u1M3Vc-AsI0TNrDVMPQHW4=.cdbf4abf-1e95-4973-9188-4e9b0480bd71@github.com>

On Tue, 27 Jan 2026 15:49:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 108:
>> 
>>> 106:         final InetAddress loopbackAddr = InetAddress.getLoopbackAddress();
>>> 107:         // port 47 is reserved - there should be nothing listening on it
>>> 108:         InetSocketAddress destAddr = new InetSocketAddress(loopbackAddr, 47);
>> 
>> a general comment on the dest port selections below, 47, 51, 61.
>> These are currently marked as reserved in the IANA port list, but if you look at the /etc/services file, on macos, you will see that there is a legacy assignment
>> 
>> As such, a comment in the test would be useful, such as,
>> 
>> // using ports 47, 51, 61 from the the IANA reserved port list, which
>> // are currently unassigned, on the assumption they will not used by
>> // a listening service
>
> Done, I've used your suggestion and updated that comment to be more descriptive.

cheers ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2732819153

From dfenacci at openjdk.org  Tue Jan 27 16:26:19 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 27 Jan 2026 16:26:19 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

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

  JDK-8374852: fix star layout
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/b79738c3..0ef73ef9

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

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

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

From jvernee at openjdk.org  Tue Jan 27 16:57:35 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 27 Jan 2026 16:57:35 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Sorry this is taking a while to review. I have been swamped since the start of the year. I want to give this patch the time it deserves, but that also means it's not possible to squeeze in the review between other things

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3806333930

From bpb at openjdk.org  Tue Jan 27 17:03:52 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Jan 2026 17:03:52 GMT
Subject: RFR: 8376419: (fs) Minor improvement of
 java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java [v2]
In-Reply-To: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
References: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
Message-ID: <g40x-G0S6ZTLRjPDa1kTP-OTUM13SQiKGQRHCA2I3kQ=.8851af14-cdb8-47b9-993c-942ed1b9258a@github.com>

> 1. Use `RandomFactory` instead of `new Random` to allow reproducibility.
> 2. Use `jtreg.SkippedException` instead of printing a message and returning silently.

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

  8376419: Align @summary text with other tests using RandomFactory

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29434/files
  - new: https://git.openjdk.org/jdk/pull/29434/files/f843deb3..a31c9b73

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

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

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

From jpai at openjdk.org  Wed Jan 28 01:15:51 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Jan 2026 01:15:51 GMT
Subject: RFR: 8376419: (fs) Minor improvement of
 java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java [v2]
In-Reply-To: <g40x-G0S6ZTLRjPDa1kTP-OTUM13SQiKGQRHCA2I3kQ=.8851af14-cdb8-47b9-993c-942ed1b9258a@github.com>
References: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
 <g40x-G0S6ZTLRjPDa1kTP-OTUM13SQiKGQRHCA2I3kQ=.8851af14-cdb8-47b9-993c-942ed1b9258a@github.com>
Message-ID: <4ZOd-GjOrZI3r7ERE4aKZHTqSWAgfAoA0nE2jXS-4U4=.bd3c3006-aca8-4934-98b1-09eff28491b9@github.com>

On Tue, 27 Jan 2026 17:03:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 1. Use `RandomFactory` instead of `new Random` to allow reproducibility.
>> 2. Use `jtreg.SkippedException` instead of printing a message and returning silently.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376419: Align @summary text with other tests using RandomFactory

Hello Brian, this looks OK to me. I just noticed one thing though - I think adding an explicit `@build jtreg.SkippedException` would be a good thing. That should prevent any intermittent/unexpected failures.

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

PR Review: https://git.openjdk.org/jdk/pull/29434#pullrequestreview-3714155897

From bpb at openjdk.org  Wed Jan 28 01:20:07 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Jan 2026 01:20:07 GMT
Subject: RFR: 8376419: (fs) Minor improvement of
 java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java [v2]
In-Reply-To: <4ZOd-GjOrZI3r7ERE4aKZHTqSWAgfAoA0nE2jXS-4U4=.bd3c3006-aca8-4934-98b1-09eff28491b9@github.com>
References: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
 <g40x-G0S6ZTLRjPDa1kTP-OTUM13SQiKGQRHCA2I3kQ=.8851af14-cdb8-47b9-993c-942ed1b9258a@github.com>
 <4ZOd-GjOrZI3r7ERE4aKZHTqSWAgfAoA0nE2jXS-4U4=.bd3c3006-aca8-4934-98b1-09eff28491b9@github.com>
Message-ID: <pOrgh-xzXP53x6Cd7nIj9k1abQaIatoJrEU-IkD2wYs=.df0be152-67c9-447e-8f37-00ed6da6b52d@github.com>

On Wed, 28 Jan 2026 01:13:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I think adding an explicit `@build jtreg.SkippedException` would be a good thing. That should prevent any intermittent/unexpected failures.

Good point. I'll update that. Thanks, @jaikiran.

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

PR Comment: https://git.openjdk.org/jdk/pull/29434#issuecomment-3808414126

From bpb at openjdk.org  Wed Jan 28 01:45:30 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Jan 2026 01:45:30 GMT
Subject: RFR: 8376419: (fs) Minor improvement of
 java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java [v3]
In-Reply-To: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
References: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
Message-ID: <IDirkXUb7uPH_pwJZpXKoPSjnVK3fg5_8S_QZyXvxlw=.f9815cf8-723a-44c0-a2e0-26b478c501c4@github.com>

> 1. Use `RandomFactory` instead of `new Random` to allow reproducibility.
> 2. Use `jtreg.SkippedException` instead of printing a message and returning silently.

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

  8376419: Add "@build jtreg.SkippedException"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29434/files
  - new: https://git.openjdk.org/jdk/pull/29434/files/a31c9b73..91e76a59

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

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

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

From jpai at openjdk.org  Wed Jan 28 01:45:30 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Jan 2026 01:45:30 GMT
Subject: RFR: 8376419: (fs) Minor improvement of
 java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java [v3]
In-Reply-To: <IDirkXUb7uPH_pwJZpXKoPSjnVK3fg5_8S_QZyXvxlw=.f9815cf8-723a-44c0-a2e0-26b478c501c4@github.com>
References: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
 <IDirkXUb7uPH_pwJZpXKoPSjnVK3fg5_8S_QZyXvxlw=.f9815cf8-723a-44c0-a2e0-26b478c501c4@github.com>
Message-ID: <MaYwBCrzXGmQ2UDu0kWBRF16n0atPvp4Xu4QZ9HQAs0=.9887663e-c870-4db7-bfb5-72d15778af8a@github.com>

On Wed, 28 Jan 2026 01:42:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 1. Use `RandomFactory` instead of `new Random` to allow reproducibility.
>> 2. Use `jtreg.SkippedException` instead of printing a message and returning silently.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376419: Add "@build jtreg.SkippedException"

Thank you Brian, looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29434#pullrequestreview-3714224349

From chagedorn at openjdk.org  Wed Jan 28 08:23:31 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 28 Jan 2026 08:23:31 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>
Message-ID: <UkcVqNuDaxfS276NoZJ6PNCpvWD-w0OfLcXEWXZH1zU=.3f3c2fcb-cbeb-4b7b-afdc-ec626eacffbb@github.com>

On Tue, 27 Jan 2026 16:26:19 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8374852: fix star layout
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

Thanks for unifying the two opaque nodes! I have some more comments.

src/hotspot/share/opto/macro.cpp line 2559:

> 2557: #else
> 2558:         bool is_positive = n->as_OpaqueCheck()->is_positive();
> 2559:         _igvn.replace_node(n, _igvn.intcon(is_positive?1:0));

Suggestion:

        _igvn.replace_node(n, _igvn.intcon(is_positive ? 1 : 0));

src/hotspot/share/opto/opaquenode.hpp line 146:

> 144: // builds, we keep the actual checks as additional verification code (i.e. removing OpaqueCheckNodes and use the
> 145: // BoolNode inputs instead).
> 146: class OpaqueCheckNode : public Node {

I've also thought about the name. `OpaqueCheck` is already a good indication what the node is about. Maybe we could go a step further and call it `OpaqueConstantBoolNode` to emphasize more that it is belonging to a `BoolNode` whose result we already know. What do you think?

Then we could also think about changing `_positive` to `_constant` (still can be a boolean to just pass true and false which seems more intuitive then passing in 1 and 0).

src/hotspot/share/opto/opaquenode.hpp line 148:

> 146: class OpaqueCheckNode : public Node {
> 147:  private:
> 148:   bool _positive;

Now that we define a field, we also need to override `size_of()` (see for example `OpaqueMultiversioningNode`).

src/hotspot/share/opto/opaquenode.hpp line 150:

> 148:   bool _positive;
> 149:  public:
> 150:   OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) {

`tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place.

src/hotspot/share/opto/opaquenode.hpp line 159:

> 157:   virtual const Type* Value(PhaseGVN* phase) const;
> 158:   virtual const Type* bottom_type() const { return TypeInt::BOOL; }
> 159:   bool is_positive() { return _positive; }

When going with `_constant`, we could turn this into

int constant() const { return _constant ? 1 : 0; }

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

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3715097474
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735306919
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735376625
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735315675
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735369034
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735392835

From alanb at openjdk.org  Wed Jan 28 12:48:48 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Jan 2026 12:48:48 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v6]
In-Reply-To: <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>
Message-ID: <yXB2islIXhb8ql97kCtu_U0W_YUuebVW3zbmHJse-Hw=.faae5d2f-b50d-4e81-a8fd-c064b8c3a640@github.com>

On Tue, 27 Jan 2026 15:55:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update code comment in test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29409#pullrequestreview-3716522015

From dfenacci at openjdk.org  Wed Jan 28 16:10:53 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 28 Jan 2026 16:10:53 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v4]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <fVjE2X-Nqf9wVrw6S2_Z6L8W732nJyBKeaZKeePFTGU=.b08e61af-3a98-407d-9933-66f8411ad18e@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with five additional commits since the last revision:

 - JDK-8374582: fix indent
 - JDK-8374582: constant
 - JDK-8374582: add size_of
 - JDK-8374852: OpaqueCheck -> OpaqueConstantBool
 - JDK-8374852: fix number of OpaqueCheck nodes in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/0ef73ef9..a3690526

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

  Stats: 162 lines in 16 files changed: 60 ins; 60 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

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

From dfenacci at openjdk.org  Wed Jan 28 16:10:57 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 28 Jan 2026 16:10:57 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <UkcVqNuDaxfS276NoZJ6PNCpvWD-w0OfLcXEWXZH1zU=.3f3c2fcb-cbeb-4b7b-afdc-ec626eacffbb@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>
 <UkcVqNuDaxfS276NoZJ6PNCpvWD-w0OfLcXEWXZH1zU=.3f3c2fcb-cbeb-4b7b-afdc-ec626eacffbb@github.com>
Message-ID: <v37o-d1AqannQfWbl4etGP5ieIpAg66YFzyECYATgBY=.70b8095e-ae47-4ad1-82ff-95ef36d0a98c@github.com>

On Wed, 28 Jan 2026 08:13:23 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8374852: fix star layout
>>   
>>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> src/hotspot/share/opto/opaquenode.hpp line 146:
> 
>> 144: // builds, we keep the actual checks as additional verification code (i.e. removing OpaqueCheckNodes and use the
>> 145: // BoolNode inputs instead).
>> 146: class OpaqueCheckNode : public Node {
> 
> I've also thought about the name. `OpaqueCheck` is already a good indication what the node is about. Maybe we could go a step further and call it `OpaqueConstantBoolNode` to emphasize more that it is belonging to a `BoolNode` whose result we already know. What do you think?
> 
> Then we could also think about changing `_positive` to `_constant` (still can be a boolean to just pass true and false which seems more intuitive then passing in 1 and 0).

I was still had a doubt about what to put first (`Constant` or `Bool`) but I think `ConstantBool` is actually more correct.

I suppose `_constant` is better than `_value` since we use it already ? 
Done.

> src/hotspot/share/opto/opaquenode.hpp line 148:
> 
>> 146: class OpaqueCheckNode : public Node {
>> 147:  private:
>> 148:   bool _positive;
> 
> Now that we define a field, we also need to override `size_of()` (see for example `OpaqueMultiversioningNode`).

Good to know. Thanks!

> src/hotspot/share/opto/opaquenode.hpp line 150:
> 
>> 148:   bool _positive;
>> 149:  public:
>> 150:   OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) {
> 
> `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place.

Hmmm... I find it hard to totally exclude a constant (e.g. if its inputs are constant...?). In that case we could skip all the opaque business (I guess in the few places where new `OpaqueConstantBool` nodes are created). On the other hand the opaque node should only really delay the folding... ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737356877
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737353309
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737355777

From dfenacci at openjdk.org  Wed Jan 28 16:23:21 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 28 Jan 2026 16:23:21 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v5]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <UVDT8Lsr8ZnIVyGdwaXI83U2QcsbyMeJvRg02OdVyww=.1658b087-d14d-4d16-996a-d18624d46176@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:

 - JDK-8374582: fix comment layout
 - JDK-8374582: fix constructor argument name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/a3690526..bddec5b5

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

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

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

From bpb at openjdk.org  Wed Jan 28 16:34:33 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Jan 2026 16:34:33 GMT
Subject: Integrated: 8376419: (fs) Minor improvement of
 java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
In-Reply-To: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
References: <XXkys58LVBaG0EOQUqKX6x2LIqJ_j6pYBnzlyNrAEvU=.75ff5114-a821-42e8-aa82-2f95b8556424@github.com>
Message-ID: <uZ8AUpVB6bislricHM1eY9PHMTN02oBBaLtgyVia9Eg=.1723f84d-b90a-400c-a994-2014e80b4c89@github.com>

On Mon, 26 Jan 2026 23:03:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> 1. Use `RandomFactory` instead of `new Random` to allow reproducibility.
> 2. Use `jtreg.SkippedException` instead of printing a message and returning silently.

This pull request has now been integrated.

Changeset: 50d872ad
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50d872ad7ac5fa5a3406517eb53d8f61f81706df
Stats:     16 lines in 1 file changed: 7 ins; 3 del; 6 mod

8376419: (fs) Minor improvement of java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java

Reviewed-by: jpai

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

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

From vyazici at openjdk.org  Wed Jan 28 19:06:27 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 28 Jan 2026 19:06:27 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v5]
In-Reply-To: <UVDT8Lsr8ZnIVyGdwaXI83U2QcsbyMeJvRg02OdVyww=.1658b087-d14d-4d16-996a-d18624d46176@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <UVDT8Lsr8ZnIVyGdwaXI83U2QcsbyMeJvRg02OdVyww=.1658b087-d14d-4d16-996a-d18624d46176@github.com>
Message-ID: <YRa29n3zMGoazIkezGYf1VazGU6gbLz548PG2bw9nrI=.42120acc-417e-44bc-870e-a148f1cb659c@github.com>

On Wed, 28 Jan 2026 16:23:21 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JDK-8374582: fix comment layout
>  - JDK-8374582: fix constructor argument name

Copyright years don't point to 2026 for the following touched files:


src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
src/hotspot/cpu/x86/macroAssembler_x86.cpp
src/hotspot/share/classfile/vmIntrinsics.hpp
src/hotspot/share/opto/classes.hpp
src/hotspot/share/opto/escape.cpp
src/hotspot/share/opto/library_call.cpp
src/hotspot/share/opto/library_call.hpp
src/hotspot/share/opto/loopTransform.cpp
src/hotspot/share/opto/loopopts.cpp
src/hotspot/share/opto/macro.cpp
src/hotspot/share/opto/node.hpp
src/hotspot/share/opto/opaquenode.cpp
src/hotspot/share/opto/opaquenode.hpp
src/hotspot/share/opto/split_if.cpp
src/java.base/share/classes/java/lang/String.java
src/java.base/share/classes/java/lang/StringCoding.java
src/java.base/share/classes/java/lang/System.java
src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
src/java.base/share/classes/sun/nio/cs/CESU_8.java
src/java.base/share/classes/sun/nio/cs/DoubleByte.java
src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java
src/java.base/share/classes/sun/nio/cs/SingleByte.java
src/java.base/share/classes/sun/nio/cs/US_ASCII.java
src/java.base/share/classes/sun/nio/cs/UTF_8.java
src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template
test/hotspot/jtreg/compiler/escapeAnalysis/TestCanReduceCheckUsersDifferentIfs.java
test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java

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

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3718529560

From jpai at openjdk.org  Thu Jan 29 06:34:01 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 Jan 2026 06:34:01 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v6]
In-Reply-To: <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>
Message-ID: <5--xWYYld1y2kY1cZxquk8_i77ZBC_I9xelhdtcsyKM=.e3b2351a-f10f-43c1-a8a7-695b7eb077c8@github.com>

On Tue, 27 Jan 2026 15:55:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update code comment in test

Thank you Alan and Mark for the reviews. tier1, tier2 and tier3 tests completed normally with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/29409#issuecomment-3815752184

From jpai at openjdk.org  Thu Jan 29 06:36:59 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 Jan 2026 06:36:59 GMT
Subject: Integrated: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <gFRge28NAgRpTn4M3vV9XTJlp2zewOuJZIE0LxAooN4=.17af47ce-ffb8-4192-8ead-cbd4a49e8a68@github.com>

On Mon, 26 Jan 2026 09:54:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

This pull request has now been integrated.

Changeset: 19c6fdf1
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19c6fdf11b01308e9f99ce5666bfffcfbc453de3
Stats:     163 lines in 4 files changed: 141 ins; 10 del; 12 mod

8376290: SocketChannel.finishConnect() contains confusing "getsockopt" in exception message for a failed connect() on Windows

Reviewed-by: alanb

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

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

From dfenacci at openjdk.org  Thu Jan 29 07:32:12 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 29 Jan 2026 07:32:12 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v6]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <o9-z7YqT6dihVbU7KFHqpMELp8i75tvIJg6tY6J_c3E=.7121e5e7-4700-4ff9-afb8-b924095ed53b@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci 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 31 additional commits since the last revision:

 - JDK-8374582: merge and update copyright year
 - Merge branch 'master' into JDK-8374582
 - Merge branch 'master' into JDK-8374582
 - JDK-8374582: fix comment layout
 - JDK-8374582: fix constructor argument name
 - JDK-8374582: fix indent
 - JDK-8374582: constant
 - JDK-8374582: add size_of
 - JDK-8374852: OpaqueCheck -> OpaqueConstantBool
 - JDK-8374852: fix number of OpaqueCheck nodes in test
 - ... and 21 more: https://git.openjdk.org/jdk/compare/7e545381...a587a269

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/bddec5b5..a587a269

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

  Stats: 61562 lines in 1281 files changed: 34520 ins; 12116 del; 14926 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

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

From dfenacci at openjdk.org  Thu Jan 29 07:32:12 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 29 Jan 2026 07:32:12 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v5]
In-Reply-To: <YRa29n3zMGoazIkezGYf1VazGU6gbLz548PG2bw9nrI=.42120acc-417e-44bc-870e-a148f1cb659c@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <UVDT8Lsr8ZnIVyGdwaXI83U2QcsbyMeJvRg02OdVyww=.1658b087-d14d-4d16-996a-d18624d46176@github.com>
 <YRa29n3zMGoazIkezGYf1VazGU6gbLz548PG2bw9nrI=.42120acc-417e-44bc-870e-a148f1cb659c@github.com>
Message-ID: <XLX15oFt15qyXhrEfUtWBNrBh1VZJh4nTVpWcHmL6C4=.013eb1ee-8fc4-4bf5-a84c-2a6bde9d2717@github.com>

On Wed, 28 Jan 2026 19:03:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Copyright years don't point to 2026 for the following touched files:

Right! Fixed. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3815950950

From smonteith at openjdk.org  Thu Jan 29 09:03:47 2026
From: smonteith at openjdk.org (Stuart Monteith)
Date: Thu, 29 Jan 2026 09:03:47 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>
Message-ID: <5izV9DyV060gChX8G_D1BvaYq6AJ2u9abAH8HmSIMKU=.a903cdd2-ec1c-4d4d-8c87-6dac4a8e32a8@github.com>

On Tue, 27 Jan 2026 16:54:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Sorry this is taking a while to review. I have been swamped since the start of the year. I want to give this patch the time it deserves, but that also means it's not possible to squeeze in the review between other things

Thanke @JornVernee , appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3816372109

From dfenacci at openjdk.org  Thu Jan 29 12:42:44 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 29 Jan 2026 12:42:44 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v7]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <y1_tSg2kFucxLE1zIBdVlAcKcIsqKPTgNoSBanfJNzI=.e1f3b33d-91ba-4af3-b5b4-a77f948520f7@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

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

  JDK-8374582: add flagless to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/a587a269..083d5698

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

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

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

From syan at openjdk.org  Thu Jan 29 13:18:58 2026
From: syan at openjdk.org (SendaoYan)
Date: Thu, 29 Jan 2026 13:18:58 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException
Message-ID: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>

Hi all,

Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.

This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

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

Commit messages:
 - 8376700: java/nio/file/DirectoryStream/SecureDS.java fails AtomicMoveNotSupportedException

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

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

From bpb at openjdk.org  Thu Jan 29 18:46:35 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 Jan 2026 18:46:35 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <aEKRwIs4TeDvsJXTSHlu93k2Px4U4m5ng8zikVti85c=.f15a71ea-fb76-4767-b947-eaad70bce281@github.com>

On Thu, 29 Jan 2026 13:11:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 30:

> 28:  * @library .. /test/lib
> 29:  * @build jdk.test.lib.Platform
> 30:  * @run main SecureDS

Might be good to add

 * @build jtreg.SkippedException

before the `@run` action.

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 37:

> 35:  * @library .. /test/lib
> 36:  * @build jdk.test.lib.Platform
> 37:  * @run main SecureDS cwd

As above, add `@build jtreg.SkippedException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2743014440
PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2743015658

From bpb at openjdk.org  Thu Jan 29 18:52:04 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 Jan 2026 18:52:04 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <J8cY4SgURFrlUP9oWmqZYbjkl-yJ34A8uT5R4RQiMGA=.030cab3d-b579-4cba-a084-4baab923612e@github.com>

On Thu, 29 Jan 2026 13:11:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 24:

> 22:  */
> 23: 
> 24: /* @test id=tmp

Instead of using IDs, it might be better to convert this test to JUnit 5 and use a `ValueSource` but not for this PR.

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 333:

> 331:             delete(dir1);
> 332:             delete(dir2);
> 333:             stream1.close();

These stream `close()` calls could be eliminated by putting lines 266-269 into a `try()` block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2743034729
PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2743027714

From bpb at openjdk.org  Thu Jan 29 19:20:03 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 Jan 2026 19:20:03 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <CcgQSJJhfVeVHUgKWwRTB3uWhnECoEfT7zSFlUGh2e4=.bff28a5b-05f3-4300-9886-456a51d98b77@github.com>

On Thu, 29 Jan 2026 13:11:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 319:

> 317:                     sds.move(file, null, file);
> 318:                 } catch (AtomicMoveNotSupportedException e) {
> 319:                     throw new SkippedException("java.nio.file.AtomicMoveNotSupportedException");

Should this instead re-throw the `AtomicMoveNotSupportedException` if `dir` is the `CWD`, i.e., the rename is within the same volume?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2743129026

From syan at openjdk.org  Fri Jan 30 00:29:43 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 30 Jan 2026 00:29:43 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v2]
In-Reply-To: <aEKRwIs4TeDvsJXTSHlu93k2Px4U4m5ng8zikVti85c=.f15a71ea-fb76-4767-b947-eaad70bce281@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
 <aEKRwIs4TeDvsJXTSHlu93k2Px4U4m5ng8zikVti85c=.f15a71ea-fb76-4767-b947-eaad70bce281@github.com>
Message-ID: <Q6Iw7-tyFBotGZMZgFZEK9WfdjfiBrZO7Aus_zS9UMs=.47ab842a-4cad-4096-8aca-bb4882242995@github.com>

On Thu, 29 Jan 2026 18:43:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @buildjtreg.SkippedException before @run
>
> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 30:
> 
>> 28:  * @library .. /test/lib
>> 29:  * @build jdk.test.lib.Platform
>> 30:  * @run main SecureDS
> 
> Might be good to add
> 
>  * @build jtreg.SkippedException
> 
> before the `@run` action.

Thanks. Fixed.

> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 37:
> 
>> 35:  * @library .. /test/lib
>> 36:  * @build jdk.test.lib.Platform
>> 37:  * @run main SecureDS cwd
> 
> As above, add `@build jtreg.SkippedException`.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2744080620
PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2744081018

From syan at openjdk.org  Fri Jan 30 00:29:40 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 30 Jan 2026 00:29:40 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v2]
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <bOFVSCHxuiwfguwIp3BBqAUxHftPMR4fw3yqpjnqOvo=.775c4f7e-9f28-407d-8218-63d9dd0e2e7f@github.com>

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

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

  Add @buildjtreg.SkippedException before @run

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29487/files
  - new: https://git.openjdk.org/jdk/pull/29487/files/3e417ec0..75464c09

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

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

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

From syan at openjdk.org  Fri Jan 30 00:35:49 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 30 Jan 2026 00:35:49 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v3]
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <ebPmZlM8Jwc2E51k-CbN2xIBgcjZNFGzDeoDBNOGdm4=.60111dee-7b20-4f4e-a92d-d90c542cfd9d@github.com>

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

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

  Revert change to test/benchmarks/micros-javac/pom.xml by mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29487/files
  - new: https://git.openjdk.org/jdk/pull/29487/files/75464c09..0770558f

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

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

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

From syan at openjdk.org  Fri Jan 30 00:50:36 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 30 Jan 2026 00:50:36 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v4]
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <aOL4pDYW3lrxeseYMmQTB9fP3cbi_ZN5JZQTenaF4zk=.ba4057b7-2d07-4b97-85cc-ffd4170ee3af@github.com>

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

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

  Remove stream.close()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29487/files
  - new: https://git.openjdk.org/jdk/pull/29487/files/0770558f..c78523f6

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

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

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

From syan at openjdk.org  Fri Jan 30 00:50:39 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 30 Jan 2026 00:50:39 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v4]
In-Reply-To: <J8cY4SgURFrlUP9oWmqZYbjkl-yJ34A8uT5R4RQiMGA=.030cab3d-b579-4cba-a084-4baab923612e@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
 <J8cY4SgURFrlUP9oWmqZYbjkl-yJ34A8uT5R4RQiMGA=.030cab3d-b579-4cba-a084-4baab923612e@github.com>
Message-ID: <Kyoyu5UeBZEb3GhJblQsKf8RzX1sP7pOBeEV-1N1cGw=.87755cd3-c33f-4f27-a4ab-0ebe399f562b@github.com>

On Thu, 29 Jan 2026 18:49:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove stream.close()
>
> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: /* @test id=tmp
> 
> Instead of using IDs, it might be better to convert this test to JUnit 5 and use a `ValueSource` but not for this PR.

I will create a new JBS issue to do that after this PR finish.

> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 333:
> 
>> 331:             delete(dir1);
>> 332:             delete(dir2);
>> 333:             stream1.close();
> 
> These stream `close()` calls could be eliminated by putting lines 266-269 into a `try()` block.

It seems that we can not only putting lines 266-269 into a `try{}` block, all about the stream1/stream2 should be in the same `try{}` block. So I remove the unnecessary `stream.close()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2744144599
PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2744142322

From syan at openjdk.org  Fri Jan 30 01:07:38 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 30 Jan 2026 01:07:38 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v5]
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <bGshn35thbHnKJ5F42UM_vDo11dXCsoK0KA5kHx2GnY=.dc1546ad-85c3-4e1d-bd05-b14126a78944@github.com>

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

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

 - Update comment
 - Re-throw the AtomicMoveNotSupportedException if renmae between the same FileStore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29487/files
  - new: https://git.openjdk.org/jdk/pull/29487/files/c78523f6..b80b72dc

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

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

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

From syan at openjdk.org  Fri Jan 30 01:11:43 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 30 Jan 2026 01:11:43 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v5]
In-Reply-To: <CcgQSJJhfVeVHUgKWwRTB3uWhnECoEfT7zSFlUGh2e4=.bff28a5b-05f3-4300-9886-456a51d98b77@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
 <CcgQSJJhfVeVHUgKWwRTB3uWhnECoEfT7zSFlUGh2e4=.bff28a5b-05f3-4300-9886-456a51d98b77@github.com>
Message-ID: <kr8Md1MXeifcKfPv2dEpOUfflBVic-qcVc3ywmfq64c=.6cb48cf2-f08f-4ace-b279-bd9921471e3d@github.com>

On Thu, 29 Jan 2026 19:17:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update comment
>>  - Re-throw the AtomicMoveNotSupportedException if renmae between the same FileStore
>
> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 319:
> 
>> 317:                     sds.move(file, null, file);
>> 318:                 } catch (AtomicMoveNotSupportedException e) {
>> 319:                     throw new SkippedException("java.nio.file.AtomicMoveNotSupportedException");
> 
> Should this instead re-throw the `AtomicMoveNotSupportedException` if `dir` is the `CWD`, i.e., the rename is within the same volume?

`dir` and `cwd` always at the different path, but maybe at the same volume. So check if they are at the some FileStore and re-throw `AtomicMoveNotSupportedException`.


Below is the actual path when run this test.

cwd: /home/yansendao/git/jdk-ysd/build/manual-run/jt-work/scratch
dir: /home/yansendao/git/jdk-ysd/build/manual-run/jt-work/scratch/name7513119775509255640

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2744193338

From syan at openjdk.org  Fri Jan 30 01:14:53 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 30 Jan 2026 01:14:53 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v6]
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <4Tc6Vy1Uozh3-nbsgyAZOboq2nzvuA6C5ahap2rirno=.691b9fbc-364b-4d5f-9d11-e7dc276ec33e@github.com>

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

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

  Revert the change of Path.of("file")

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29487/files
  - new: https://git.openjdk.org/jdk/pull/29487/files/b80b72dc..8751d344

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

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

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

From bpb at openjdk.org  Fri Jan 30 02:53:09 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Jan 2026 02:53:09 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v6]
In-Reply-To: <Kyoyu5UeBZEb3GhJblQsKf8RzX1sP7pOBeEV-1N1cGw=.87755cd3-c33f-4f27-a4ab-0ebe399f562b@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
 <J8cY4SgURFrlUP9oWmqZYbjkl-yJ34A8uT5R4RQiMGA=.030cab3d-b579-4cba-a084-4baab923612e@github.com>
 <Kyoyu5UeBZEb3GhJblQsKf8RzX1sP7pOBeEV-1N1cGw=.87755cd3-c33f-4f27-a4ab-0ebe399f562b@github.com>
Message-ID: <iDDONLym9nS1CdUF6Gt_PqgAXQQSwSBobXrUhU7q-os=.0057f248-7f14-44e0-9127-65ff2e902240@github.com>

On Fri, 30 Jan 2026 00:47:06 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 24:
>> 
>>> 22:  */
>>> 23: 
>>> 24: /* @test id=tmp
>> 
>> Instead of using IDs, it might be better to convert this test to JUnit 5 and use a `ValueSource` but not for this PR.
>
> I will create a new JBS issue to do that after this PR finish.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2744392794

From bpb at openjdk.org  Fri Jan 30 02:59:07 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Jan 2026 02:59:07 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v6]
In-Reply-To: <kr8Md1MXeifcKfPv2dEpOUfflBVic-qcVc3ywmfq64c=.6cb48cf2-f08f-4ace-b279-bd9921471e3d@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
 <CcgQSJJhfVeVHUgKWwRTB3uWhnECoEfT7zSFlUGh2e4=.bff28a5b-05f3-4300-9886-456a51d98b77@github.com>
 <kr8Md1MXeifcKfPv2dEpOUfflBVic-qcVc3ywmfq64c=.6cb48cf2-f08f-4ace-b279-bd9921471e3d@github.com>
Message-ID: <Q7bI7UjytPhv6V1DYMJaiwFhl2t057gxN6IBRYXKpo0=.7cb3944b-2e67-4441-8b26-31677ad7b7bf@github.com>

On Fri, 30 Jan 2026 01:09:22 GMT, SendaoYan <syan at openjdk.org> wrote:

> So check if they are at the some FileStore and re-throw `AtomicMoveNotSupportedException`.

Okay, good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2744402724

From chagedorn at openjdk.org  Fri Jan 30 10:47:17 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 30 Jan 2026 10:47:17 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v7]
In-Reply-To: <y1_tSg2kFucxLE1zIBdVlAcKcIsqKPTgNoSBanfJNzI=.e1f3b33d-91ba-4af3-b5b4-a77f948520f7@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <y1_tSg2kFucxLE1zIBdVlAcKcIsqKPTgNoSBanfJNzI=.e1f3b33d-91ba-4af3-b5b4-a77f948520f7@github.com>
Message-ID: <K0y8_ePOPY1HjkjWcM1Fg8t-yhljHI_h1Qt25M3HOQ0=.9d7f61ab-5011-4c63-8ac7-593b6bbbb0af@github.com>

On Thu, 29 Jan 2026 12:42:44 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8374582: add flagless to test

src/hotspot/share/opto/library_call.cpp line 894:

> 892: 
> 893: inline Node* LibraryCallKit::generate_negative_guard(Node* index, RegionNode* region,
> 894:                                                      Node* *pos_index, bool is_opaque) {

Suggestion:

                                                     Node** pos_index, bool is_opaque) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2745638291

From chagedorn at openjdk.org  Fri Jan 30 10:47:19 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 30 Jan 2026 10:47:19 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <v37o-d1AqannQfWbl4etGP5ieIpAg66YFzyECYATgBY=.70b8095e-ae47-4ad1-82ff-95ef36d0a98c@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>
 <UkcVqNuDaxfS276NoZJ6PNCpvWD-w0OfLcXEWXZH1zU=.3f3c2fcb-cbeb-4b7b-afdc-ec626eacffbb@github.com>
 <v37o-d1AqannQfWbl4etGP5ieIpAg66YFzyECYATgBY=.70b8095e-ae47-4ad1-82ff-95ef36d0a98c@github.com>
Message-ID: <qAgw17uyYg8a3YP6IrSEzgQc1zN8rxjThQGGFYlWWlI=.9c983e56-8166-4128-b9c9-6f8ed900ce56@github.com>

On Wed, 28 Jan 2026 16:02:56 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> src/hotspot/share/opto/opaquenode.hpp line 150:
>> 
>>> 148:   bool _positive;
>>> 149:  public:
>>> 150:   OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) {
>> 
>> `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place.
>
> Hmmm... I find it hard to totally exclude a constant (e.g. if its inputs are constant...?). In that case we could skip all the opaque business (I guess in the few places where new `OpaqueConstantBool` nodes are created). On the other hand the opaque node should only really delay the folding... ?

I think folding is fine since we implement `Value()` to take the input's `Value()`. My understanding is that we insert an additional check that is actually not needed because we already checked it in Java code. So, it should be true at that point but C2 does not know that. We still insert the check in order to make sure to also fold control away if data is dying. Once we know that data will not die anymore, we can remove the useless check again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2745545348

From dfenacci at openjdk.org  Fri Jan 30 13:56:01 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 30 Jan 2026 13:56:01 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <ruhbSt_5vfLBYmPoZN6_GkdXbS3oxDKsvtvR1hDInZk=.69425870-3c7f-4ec0-a06f-a43e5cae4900@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

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

  JDK-8374582: fix star layout
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/083d5698..c5390e4a

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

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

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

From duke at openjdk.org  Sat Jan 31 08:15:55 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 31 Jan 2026 08:15:55 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v16]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <dsu74QJ8kyyGzhGztsb7Pi11tlf7hsUJ5ZETf6z7voc=.6e873181-3407-4a60-b785-32a7ffa2c63b@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

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

  Add `codePointCount` for `CharBuffer`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/585ce36e..a291e1bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=14-15

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

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

From alanb at openjdk.org  Sat Jan 31 08:51:10 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 31 Jan 2026 08:51:10 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v16]
In-Reply-To: <dsu74QJ8kyyGzhGztsb7Pi11tlf7hsUJ5ZETf6z7voc=.6e873181-3407-4a60-b785-32a7ffa2c63b@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <dsu74QJ8kyyGzhGztsb7Pi11tlf7hsUJ5ZETf6z7voc=.6e873181-3407-4a60-b785-32a7ffa2c63b@github.com>
Message-ID: <ABIB3iLpydNy4_u5MhQGsK7zp_h0sNRL9M7z2SW8mlQ=.ba7e9779-d251-4179-b117-a62aab8ccfa5@github.com>

On Sat, 31 Jan 2026 08:15:55 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `codePointCount` for `CharBuffer`

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

> 2060:     /**
> 2061:      * {@return the number of Unicode code points in this character sequence}
> 2062:      * Isolated surrogate code units count as one code point each.

I agree the override needs to be specified but it will need to be specified to count the code points in the between the position (inclusive) and the limit (exclusive).

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

> 2068:         int lim = limit();
> 2069:         int count = l;
> 2070:         for (int i = position(); i < lim;) {

There will need to a robustness pass done on this override as the CharBuffer may be backed by off-heap memory. Look at the existing overides to see examples where it captures the limit and position once.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749219147
PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749219908

From duke at openjdk.org  Sat Jan 31 12:51:41 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 31 Jan 2026 12:51:41 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v17]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <jEeykNVM-U1rBEwA-jjwW5BBW4e7C_JfMYqWxP7vkSU=.a479d0bc-7c1c-464e-a352-574ebccdf6bc@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

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

  Fix incorrect logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/a291e1bb..77583bdc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=15-16

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

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

From duke at openjdk.org  Sat Jan 31 12:51:43 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 31 Jan 2026 12:51:43 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v16]
In-Reply-To: <ABIB3iLpydNy4_u5MhQGsK7zp_h0sNRL9M7z2SW8mlQ=.ba7e9779-d251-4179-b117-a62aab8ccfa5@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <dsu74QJ8kyyGzhGztsb7Pi11tlf7hsUJ5ZETf6z7voc=.6e873181-3407-4a60-b785-32a7ffa2c63b@github.com>
 <ABIB3iLpydNy4_u5MhQGsK7zp_h0sNRL9M7z2SW8mlQ=.ba7e9779-d251-4179-b117-a62aab8ccfa5@github.com>
Message-ID: <OpWJ_NSRSu4LXEYYHOY6naB_BGfw-AVzEZyamNPZdfY=.1d4bce16-071d-4271-9657-5a67e3f57da1@github.com>

On Sat, 31 Jan 2026 08:48:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add `codePointCount` for `CharBuffer`
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 2070:
> 
>> 2068:         int lim = limit();
>> 2069:         int count = l;
>> 2070:         for (int i = position(); i < lim;) {
> 
> There will need a robustness pass done on this override as the CharBuffer may be backed by off-heap memory. Look at the existing overrides to see examples where it captures the limit and position once.

In the first place the logic turned out to be wrong. Could you give me more concrete comment based on the new change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749529891

From duke at openjdk.org  Sat Jan 31 13:34:49 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 31 Jan 2026 13:34:49 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v18]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <56CnxfQ7B7MlL4-tu2Cs-J1gmwAc0OGKM72ApDqIRmk=.72d806d0-4b0c-44c5-b310-b628c16b24fd@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with three additional commits since the last revision:

 - Split testcases for `StringBuilder.codePointCount`
 - Update year
 - Improve JavaDoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/77583bdc..cabb3efe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=16-17

  Stats: 31 lines in 3 files changed: 19 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26461.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461

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

From duke at openjdk.org  Sat Jan 31 13:34:52 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 31 Jan 2026 13:34:52 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v16]
In-Reply-To: <ABIB3iLpydNy4_u5MhQGsK7zp_h0sNRL9M7z2SW8mlQ=.ba7e9779-d251-4179-b117-a62aab8ccfa5@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <dsu74QJ8kyyGzhGztsb7Pi11tlf7hsUJ5ZETf6z7voc=.6e873181-3407-4a60-b785-32a7ffa2c63b@github.com>
 <ABIB3iLpydNy4_u5MhQGsK7zp_h0sNRL9M7z2SW8mlQ=.ba7e9779-d251-4179-b117-a62aab8ccfa5@github.com>
Message-ID: <pJtN4lGGZPW2Jnc5miz02mdweLjKZc4fcFc0Iz1VDlU=.f53f2d57-90c1-40e6-ad92-67c876276917@github.com>

On Sat, 31 Jan 2026 08:46:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add `codePointCount` for `CharBuffer`
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 2062:
> 
>> 2060:     /**
>> 2061:      * {@return the number of Unicode code points in this character sequence}
>> 2062:      * Isolated surrogate code units count as one code point each.
> 
> I agree the override needs to be specified but it will need to be specified to count the code points between the position (inclusive) and the limit (exclusive).

JavaDoc updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749563799

From duke at openjdk.org  Sat Jan 31 13:34:54 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 31 Jan 2026 13:34:54 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v14]
In-Reply-To: <O_vvvZQi8sGxjXWARYO1a-pQuP2iwU7_JUMf4wVdGp8=.828756e5-596f-4731-a4b5-a1d636b7f2ea@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <EUxZkrb4Whuz6L2_mWBcjV5QpReLWV4sCaPTRiT42CA=.e7718b88-67d9-413e-a3f6-ef2744658444@github.com>
 <KzsQxiOI-dzO9FxOKKclwaW2o2V5yZMhFjVtmalrAds=.7558816a-f4a7-450a-9d1e-852fcbf1a7b7@github.com>
 <XJiiH-i8sYmYHL0zzJE4LUpoY_m_spmI98bS1OJJn4w=.c8b28171-2ea2-42c2-81d4-3eefcf843afc@github.com>
 <O_vvvZQi8sGxjXWARYO1a-pQuP2iwU7_JUMf4wVdGp8=.828756e5-596f-4731-a4b5-a1d636b7f2ea@github.com>
Message-ID: <c_VInZTiWqd8rsPIStI2MAKKqduaX63HWBknCPjCxo0=.75268626-730c-479f-bfb1-a3f9b5ef91dd@github.com>

On Fri, 30 Jan 2026 16:20:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> Bonus if you could rename each testX to testMethodName
>> 
>> "`testCodePointCount`" has already been occupied:
>> 
>> https://github.com/tats-u/jdk/blob/585ce36e125ec2f79483311512d8789ff39b0df9/test/jdk/java/lang/StringBuilder/Supplementary.java#L365-L376
>> 
>> https://github.com/tats-u/jdk/blob/585ce36e125ec2f79483311512d8789ff39b0df9/test/jdk/java/lang/StringBuilder/Supplementary.java#L247-L251
>
> We could distinguish them like `testCodePointCountNoArg` and `testCodePointCountTwoArgs`

I see

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749563375

From duke at openjdk.org  Sat Jan 31 14:31:39 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 31 Jan 2026 14:31:39 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v19]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <vLfXZ_nl-H0QIpj9JDobVTiYBXUNh13WG4HodaXr14s=.f61a7568-900f-4f2b-b9ea-90e2b92561ec@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

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

  Add missing semicolon

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/cabb3efe..81245159

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=17-18

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

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

From alanb at openjdk.org  Sat Jan 31 15:59:07 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 31 Jan 2026 15:59:07 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v19]
In-Reply-To: <vLfXZ_nl-H0QIpj9JDobVTiYBXUNh13WG4HodaXr14s=.f61a7568-900f-4f2b-b9ea-90e2b92561ec@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <vLfXZ_nl-H0QIpj9JDobVTiYBXUNh13WG4HodaXr14s=.f61a7568-900f-4f2b-b9ea-90e2b92561ec@github.com>
Message-ID: <ln_25-aBVrSjkE5REb-0wTho1kUCecFBAMCEdv4VzG4=.f626e677-18b9-4270-82d5-0776d8300a99@github.com>

On Sat, 31 Jan 2026 14:31:39 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing semicolon

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

> 2059: 
> 2060:     /**
> 2061:      * {@return the number of Unicode code points in this character sequence

Can you change the first sentence to : "{@return the number of Unicode code points in this character buffer}".

The rest can go into a second paragraph that starts with "The number of Unicode code points in this character buffer is the number of Unicode code points between the position (inclusive) and the limit (exclusive).".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749697267