read-write

{@code
> 313:      * dstbegin + (srcEnd-srcBegin) - 1

Shouldn't it be dstBegin?

* dstBegin + (srcEnd-srcBegin) - 1

src/java.base/share/classes/java/lang/CharSequence.java line 329:

> 327:      *             {@code this.length()}.
> 328:      *             {@code dstBegin+srcEnd-srcBegin} is greater than
> 329:      *             {@code dst.length}

I think we should have `.` at the end of each case. Now it's inconsistent

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2082456985
PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2082459665

From bpb at openjdk.org  Fri May  9 22:32:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 22:32:50 GMT
Subject: RFR: 8356127: (fs) UnixFileSystemProvider.implDelete could save a
 syscall in some cases [v3]
In-Reply-To: 
References: <__DpX8NhzRrLcm-Ev8Z7HovPQqJolMCEcWerlNYvyUg=.9e95dad9-640b-4ebb-9dae-977c216dc3ce@github.com>
 
 <_tmc-y1SKXOJbqGypPX5JNi6dzDvhrgv41VwpzxK_7A=.8c2dd1c1-aeb7-4771-a357-f093b84341ee@github.com>
 
 
 <8mOBk56Zaqo1KTinUbQm0QrLq-xL21mUjaf4O5AuSiE=.ef062a83-cd68-4137-9a72-c309fcf6f1bf@github.com>
 
 
 <_grJggFbxOgB93F8aKoWKNXJw_qyfIo5iqZXs37kLMY=.425b9fd3-b2f9-4701-82ba-7fada1b86e74@github.com>
 
Message-ID: 

On Fri, 9 May 2025 17:01:09 GMT, Alan Bateman  wrote:

>>> It might be worth digging into how this works in NFS environments.
>> 
>> I will try to assess this.
>
> I have a vague memory that NFSv4 had changes in this area to allow the REMOVE RPC handle any file type. Getting an up to date summary on that would be helpful as it may be that the change here will only work on local file systems.

A safer approach would be to remove the capability check and not to rely on the value of `errno` at all.

        boolean isDirectory = false;
        try {
            try {
                // assume the common case that the file is a regular file
                unlink(file);
            } catch (UnixException e) {
                // check whether the file is a directory and, if so,
                // try rmdir, otherwise re-throw and let the exception
                // be handled below
                isDirectory = UnixFileAttributes.get(file, false).isDirectory();
                if (isDirectory) {
                    rmdir(file);
                } else {
                    throw e;
                }   
            }
            return true;
        } catch (UnixException x) {
            // .... handle the exception ...
        }

Of course this would be at the expense of a `stat` if the `unlink` fails, but that would at least be avoided for the common case of deleting a regular file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25107#discussion_r2082574592

From bpb at openjdk.org  Fri May  9 22:49:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 22:49:27 GMT
Subject: RFR: 8351415: (fs) Path::toAbsolutePath should specify if an absolute
 path has a root component
Message-ID: 

Add a sentence to the specification of `Path::toAbsolutePath` indicating that the root component of the absolute path derived from a `Path` associated with the default provider is non-`null`.

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

Commit messages:
 - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component

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

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

From bpb at openjdk.org  Fri May  9 22:53:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 22:53:15 GMT
Subject: RFR: 8356606: PosixFileAttributes.permissions() implementations should
 return an EnumSet
Message-ID: 

Drop-in replacement in `sun.nio.fs.UnixFileAttributes::permissions` of `HashSet` with `EnumSet` for hopefully improved efficiency. All tests containing `PosixFileAttributes` passed.

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

Commit messages:
 - 8356606: PosixFileAttributes.permissions() implementations should return an EnumSet

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

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

From liach at openjdk.org  Fri May  9 23:05:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 23:05:49 GMT
Subject: RFR: 8356606: (fs) PosixFileAttributes.permissions()
 implementations should return an EnumSet
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 May 2025 22:48:11 GMT, Brian Burkhalter  wrote:

> Drop-in replacement in `sun.nio.fs.UnixFileAttributes::permissions` of `HashSet` with `EnumSet` for hopefully improved efficiency. All tests containing `PosixFileAttributes` passed.

Makes sense. This rejects usages of adding null or invalid objects, but this still abides to the specs, that the returned set can be modified and passed to create new attributes.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25162#pullrequestreview-2829850578

From alanb at openjdk.org  Sat May 10 06:22:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 May 2025 06:22:54 GMT
Subject: RFR: 8356606: (fs) PosixFileAttributes.permissions()
 implementations should return an EnumSet
In-Reply-To: 
References: 
Message-ID: <7A00QvaDBh5e5xuvoysuQJCFPLgNW_7O7_55iOLREGU=.f99914f1-ff2f-4ce3-aa26-bec178fd9087@github.com>

On Fri, 9 May 2025 22:48:11 GMT, Brian Burkhalter  wrote:

> Drop-in replacement in `sun.nio.fs.UnixFileAttributes::permissions` of `HashSet` with `EnumSet` for hopefully improved efficiency. All tests containing `PosixFileAttributes` passed.

I assume reading POSIX file permissions is going to be dominated by stat/equivalent, it might be that the JBS issue was more of a suggestion from someone reading the code?

In any case, it looks fine and I assume you'll run the jdk_nio tests.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25162#pullrequestreview-2830393769

From alanb at openjdk.org  Sat May 10 08:07:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 May 2025 08:07:51 GMT
Subject: RFR: 8356127: (fs) UnixFileSystemProvider.implDelete could save a
 syscall in some cases [v5]
In-Reply-To: 
References: <__DpX8NhzRrLcm-Ev8Z7HovPQqJolMCEcWerlNYvyUg=.9e95dad9-640b-4ebb-9dae-977c216dc3ce@github.com>
 
Message-ID: 

On Fri, 9 May 2025 16:56:09 GMT, Brian Burkhalter  wrote:

>> Modify `UnixFileSystemProvider.implDelete` to attempt first to delete the file using `unlink` and, if that fails, fall back to using `rmdir` if the file is a directory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356127: Tweak previous commit

I think we have to cautious and spend more time understanding the behavior of unlink with non-empty directories. I'm pretty sure that back in SunOS and UFS days that a non-empty directory could be unlinked, think cleanup when doing the next fsck. I understand that the proposal is do this on Linux only and it will work for local file systems. However, it is not clear to me that this is reliable with remote file systems. NFSv4 did make changes to support exactly what it is doing proposed but I worry there are other remote file systems where we might not get the ENOTEMPTY. Doing a statvfs to check the file system type would work but probably more expensive that the stat that we do now to check if the file is a directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/25107#issuecomment-2868618444

From jpai at openjdk.org  Mon May 12 01:20:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 01:20:07 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 9 May 2025 20:35:04 GMT, Andrey Turbanov  wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - merge latest from master branch
>>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>>  - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'
>>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a
>
> src/java.base/share/classes/java/lang/CharSequence.java line 313:
> 
>> 311:      * at index {@code dstBegin} and ending at index:
>> 312:      * {@code
>> 313:      * dstbegin + (srcEnd-srcBegin) - 1
> 
> Shouldn't it be dstBegin?
> 
> * dstBegin + (srcEnd-srcBegin) - 1

Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2083686557

From alanb at openjdk.org  Mon May 12 07:35:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 07:35:52 GMT
Subject: RFR: 8351415: (fs) Path::toAbsolutePath should specify if an
 absolute path has a root component
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 May 2025 22:44:04 GMT, Brian Burkhalter  wrote:

> Add a sentence to the specification of `Path::toAbsolutePath` indicating that the root component of the absolute path derived from a `Path` associated with the default provider is non-`null`.

I think it is okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25161#pullrequestreview-2832128143

From duke at openjdk.org  Mon May 12 09:45:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 09:45:02 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
Message-ID: 

Adding read-only support to ZipFileSystem.

The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.

This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.

By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

Commit messages:
 - Read only Zip file system support.

Changes: https://git.openjdk.org/jdk/pull/25178/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350880
  Stats: 373 lines in 5 files changed: 310 ins; 20 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

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

From duke at openjdk.org  Mon May 12 10:05:59 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 10:05:59 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 May 2025 09:40:56 GMT, David Beaumont  wrote:

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

Preloading some explanatory comment.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 83:

> 81:     private static final boolean isWindows = System.getProperty("os.name")
> 82:             .startsWith("Windows");
> 83:     private static final byte[] ROOTPATH = new byte[]{'/'};

Whitespace format changes from my editor - will revert (sorry hadn't spotted).

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 89:

> 87: 
> 88:     // Posix file permissions allow per-file access control in a posix-like fashion.
> 89:     // Note that using a "readOnly" access mode will force all files, and the

Not correct now - will fix.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 198:

> 196:         this.defaultOwner = supportPosix ? initOwner(zfpath, env) : null;
> 197:         this.defaultGroup = supportPosix ? initGroup(zfpath, env) : null;
> 198:         this.defaultPermissions = supportPosix ? Collections.unmodifiableSet(initPermissions(env)) : null;

Ensuring this is unmodifiable to avoid risk of returning a modifiable enum set.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221:

> 219:         }
> 220:         // sm and existence check
> 221:         zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ);

Type name clash with existing AccessMode class. Since new enum is private, happy to rename.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241:

> 239:         // is why they are the only non-final fields), and it requires that the
> 240:         // inode map has been initialized.
> 241:         Optional multiReleaseVersion = determineReleaseVersion(env);

Now release version and entry lookup determination always happen on a read-only file system.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259:

> 257: 
> 258:         // Pass "this" as a parameter after everything else is set up.
> 259:         this.rootdir = new ZipPath(this, new byte[]{'/'});

This could probably be set above release version etc. but it's a choice of either:
1. waiting until everything is set up before passing "this"
2. letting an incomplete "this" instance get passed to another class (possible escape risk?)

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 264:

> 262:     /**
> 263:      * Return the compression method to use (STORED or DEFLATED).  If the
> 264:      * property {@code compressionMethod} is set use its value to determine

Typo fix (too many m's).

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 377:

> 375:         Object o = env.get(PROPERTY_DEFAULT_PERMISSIONS);
> 376:         if (o == null) {
> 377:             return PosixFilePermissions.fromString("rwxrwxrwx");

Since DEFAULT_PERMISSIONS was mutable and only used exactly once, it seems better to just inline it where it's clear what it actually is based off. Better readability.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1458:

> 1456:      * use its value to determine the requested version. If not use the value of the "multi-release" property.
> 1457:      */
> 1458:     private Optional determineReleaseVersion(Map env) throws IOException {

Refactored to return the value rather than side-effect instance fields.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 180:

> 178:      */
> 179:     @Test
> 180:     public void testNoSuchFileFailure() {

In theory some of these could be split more, but they are uncomplicated sanity checks.

test/jdk/jdk/nio/zipfs/Utils.java line 52:

> 50:      */
> 51:     static Path createJarFile(String name, String... entries) throws IOException {
> 52:         Path jarFile = Paths.get(name);

Previous tests always had the test file called the same thing.
Note that in jtreg tests, the file of the same name often already exists in the test directory.
I tried adding a "ensure file doesn't already exist" check and it fails lots of tests.

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

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2832583353
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084284309
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084288335
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084292488
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084296094
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084297859
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084301697
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084302415
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084306071
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084307536
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084311454
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084317768

From duke at openjdk.org  Mon May 12 10:11:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 10:11:11 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v2]
In-Reply-To: 
References: 
Message-ID: <1WMrvLWTwMWR2ECtF4E8hcQXIL1sxeQA4Cf1mamF6Ho=.80041034-907d-48aa-957c-108d59c3b3e8@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Remove unwanted reformatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/da3dfc6f..376e3acf

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

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

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

From duke at openjdk.org  Mon May 12 10:16:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 10:16:33 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
Message-ID: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Fix comment based on current behaviour.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/376e3acf..9b356a24

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

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

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

From duke at openjdk.org  Mon May 12 10:21:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 10:21:50 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

Obvious mistakes now fixed (it's amazing what you only spot when looking at code in a review UI).

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

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2871935949

From duke at openjdk.org  Mon May 12 10:37:04 2025
From: duke at openjdk.org (Markus KARG)
Date: Mon, 12 May 2025 10:37:04 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 12 May 2025 01:17:15 GMT, Jaikiran Pai  wrote:

>> src/java.base/share/classes/java/lang/CharSequence.java line 313:
>> 
>>> 311:      * at index {@code dstBegin} and ending at index:
>>> 312:      * {@code
>>> 313:      * dstbegin + (srcEnd-srcBegin) - 1
>> 
>> Shouldn't it be dstBegin?
>> 
>> * dstBegin + (srcEnd-srcBegin) - 1
>
> Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?

We could also simply include it in the PR for https://bugs.openjdk.org/browse/JDK-8356679 to reduce organizational overhead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2084384684

From duke at openjdk.org  Mon May 12 13:59:57 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 12 May 2025 13:59:57 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 9 May 2025 06:37:40 GMT, Alan Bateman  wrote:

> No, it will still uses synchronized if there is contention and this will not consume the park permit when it's a virtual thread. Im not sure if Heinz ran into an issue, or just remember the issue from 2015, Heinz?

I saw this comment in the JavaDoc of LockSupport: https://github.com/openjdk/jdk/blob/7ae52ce572794f9d17446c66381f703ea1bb8b7c/src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java#L135 

I then searched through the JDK classes and the only ones that used LockSupport and that did not have the static {var clazz = LockSupport.class;} were the newer classes that arrived with Java 19, plus also Exchanger (which may have been an oversight).

If this is no longer an issue, and we are 100% sure of that, then we can perhaps change the example to not have that static loader?

I have not tried to reproduce the bug, and from what Martin Buchholz described it is extremely elusive.

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

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2872683811

From dfuchs at openjdk.org  Mon May 12 15:18:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 15:18:53 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 9 May 2025 19:18:58 GMT, Daniel Fuchs  wrote:

>> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 214:
>> 
>>> 212:      */
>>> 213:     @Override
>>> 214:     @Deprecated(since = "25", forRemoval = true)
>> 
>> Is this annotation required or more as a reminder that the superclass method is deprecated?
>
> I think it's needed because the superclass method is deprecated for removal. Will double check.

Yes - it is needed. If you override a deprecated method you need to carry the deprecation annotation over. Here is what I got when I tried to remove the annotation on `HttpURLConnection::getPermission()` (the same error occurred on any subclass where I attempted to remove the annotation):

java/net/HttpURLConnection.java:615: warning: [dep-ann] deprecated item is not annotated with @Deprecated
    public Permission getPermission() throws IOException {
                      ^
error: warnings found and -Werror specified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2084915172

From dfuchs at openjdk.org  Mon May 12 15:24:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 15:24:52 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 9 May 2025 19:19:03 GMT, Daniel Fuchs  wrote:

>> src/java.base/share/classes/java/net/HttpURLConnection.java line 615:
>> 
>>> 613:      */
>>> 614:     @Deprecated(since = "25", forRemoval = true)
>>> 615:     @SuppressWarnings("removal")
>> 
>> Do you still need this annotation now that `SocketPermission` is not deprecated for removal?
>
> Ah - good point - I will double check.

Yes - it is needed as well. Apparently if you override a deprecated method you need both `@Deprecated` and `@SuppressWarning`:


src/java.base/share/classes/java/net/HttpURLConnection.java:615: warning: [removal] getPermission() in URLConnection has been deprecated and marked for removal
    public Permission getPermission() throws IOException {
                      ^
error: warnings found and -Werror specified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2084927109

From bpb at openjdk.org  Mon May 12 15:34:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 15:34:52 GMT
Subject: RFR: 8356606: (fs) PosixFileAttributes.permissions()
 implementations should return an EnumSet
In-Reply-To: <7A00QvaDBh5e5xuvoysuQJCFPLgNW_7O7_55iOLREGU=.f99914f1-ff2f-4ce3-aa26-bec178fd9087@github.com>
References: 
 <7A00QvaDBh5e5xuvoysuQJCFPLgNW_7O7_55iOLREGU=.f99914f1-ff2f-4ce3-aa26-bec178fd9087@github.com>
Message-ID: 

On Sat, 10 May 2025 06:20:40 GMT, Alan Bateman  wrote:

> In any case, it looks fine and I assume you'll run the jdk_nio tests.

Yes. I already ran those that mention `PosixFileAttributes` but I'll run all the `jdk_nio` tests for safety.

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

PR Comment: https://git.openjdk.org/jdk/pull/25162#issuecomment-2873033445

From alanb at openjdk.org  Mon May 12 16:06:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 16:06:52 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/module-info.java line 160:

> 158:  *       will always be opened read-write (see {@code "accessMode"}
> 159:  *       below), regardless of whether the underlying ZIP already existed or
> 160:  *       not.

In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist.

For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system.

src/jdk.zipfs/share/classes/module-info.java line 281:

> 279:  *       Even if a zip file system is writable ({@code fs.isReadOnly() == false}),
> 280:  *       this says nothing about whether individual files can be created or
> 281:  *       modified, simply that it might be possible.

Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084997941
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085009060

From mullan at openjdk.org  Mon May 12 16:22:59 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:22:59 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 12 May 2025 15:21:46 GMT, Daniel Fuchs  wrote:

>> Ah - good point - I will double check.
>
> Yes - it is needed as well. Apparently if you override a deprecated method you need both `@Deprecated` and `@SuppressWarning`:
> 
> 
> src/java.base/share/classes/java/net/HttpURLConnection.java:615: warning: [removal] getPermission() in URLConnection has been deprecated and marked for removal
>     public Permission getPermission() throws IOException {
>                       ^
> error: warnings found and -Werror specified

Ok, but seems redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2085033749

From mullan at openjdk.org  Mon May 12 16:27:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:27:54 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs  wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2833821389

From bpb at openjdk.org  Mon May 12 16:36:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 16:36:52 GMT
Subject: RFR: 8351415: (fs) Path::toAbsolutePath should specify if an
 absolute path has a root component
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 May 2025 22:44:04 GMT, Brian Burkhalter  wrote:

> Add a sentence to the specification of `Path::toAbsolutePath` indicating that the root component of the absolute path derived from a `Path` associated with the default provider is non-`null`.

> /csr

Created.

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

PR Comment: https://git.openjdk.org/jdk/pull/25161#issuecomment-2873242565

From bpb at openjdk.org  Mon May 12 16:50:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 16:50:58 GMT
Subject: RFR: 8356606: (fs) PosixFileAttributes.permissions()
 implementations should return an EnumSet
In-Reply-To: 
References: 
 <7A00QvaDBh5e5xuvoysuQJCFPLgNW_7O7_55iOLREGU=.f99914f1-ff2f-4ce3-aa26-bec178fd9087@github.com>
 
Message-ID: 

On Mon, 12 May 2025 15:31:49 GMT, Brian Burkhalter  wrote:

> [...] I'll run all the `jdk_nio` tests for safety.

Passed on Linux and macOS.

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

PR Comment: https://git.openjdk.org/jdk/pull/25162#issuecomment-2873275621

From bpb at openjdk.org  Mon May 12 16:50:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 16:50:59 GMT
Subject: Integrated: 8356606: (fs) PosixFileAttributes.permissions()
 implementations should return an EnumSet
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 May 2025 22:48:11 GMT, Brian Burkhalter  wrote:

> Drop-in replacement in `sun.nio.fs.UnixFileAttributes::permissions` of `HashSet` with `EnumSet` for hopefully improved efficiency. All tests containing `PosixFileAttributes` passed.

This pull request has now been integrated.

Changeset: 8d7866ef
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/8d7866ef5fbf98eae6f30c4a6199a0e709f445a5
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8356606: (fs) PosixFileAttributes.permissions() implementations should return an EnumSet

Reviewed-by: liach, alanb

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

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

From dfuchs at openjdk.org  Mon May 12 16:52:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 16:52:57 GMT
Subject: Integrated: 8353642: Deprecate URL::getPermission method and
 networking permission classes for removal
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs  wrote:

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

This pull request has now been integrated.

Changeset: 45dfc2c6
Author:    Daniel Fuchs 
URL:       https://git.openjdk.org/jdk/commit/45dfc2c6d6d6b2b0749347b0150bb22d49f12767
Stats:     41 lines in 11 files changed: 25 ins; 4 del; 12 mod

8353642: Deprecate URL::getPermission method and networking permission classes for removal

Reviewed-by: djelinski, iris, mullan, michaelm

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

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

From bpb at openjdk.org  Mon May 12 19:41:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 19:41:14 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix)
Message-ID: 

Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.

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

Commit messages:
 - 8356678: (fs) Files.readAttributes should map ENOTDIR to NoSuchFileException where possible (unix)

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

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

From bpb at openjdk.org  Mon May 12 19:41:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 19:41:14 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 May 2025 19:36:22 GMT, Brian Burkhalter  wrote:

> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.

In addition to the changes provided in `fs.patch` attached to the issue, there is a change to `UnixFileSystem` to handle the same situation in `Files.copy`, and a new test is added.

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

PR Comment: https://git.openjdk.org/jdk/pull/25191#issuecomment-2873774990

From duke at openjdk.org  Mon May 12 20:15:52 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 20:15:52 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: 

On Mon, 12 May 2025 16:04:22 GMT, Alan Bateman  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/module-info.java line 281:
> 
>> 279:  *       Even if a zip file system is writable ({@code fs.isReadOnly() == false}),
>> 280:  *       this says nothing about whether individual files can be created or
>> 281:  *       modified, simply that it might be possible.
> 
> Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean?

Hmm, you're right, it's not totally clear. It's trying to draw the same sort of distinction that you have with mounted file systems, in which the mode that something is mounted in doesn't override any underlying read-only state.

For example you can still open a ZipFileSystem for a ZIP file which is on a remote drive, where the permissions show the underlying file as "writable", but an attempt to modify the contents would still fail.

The POSIX stuff is mentioned at the end, and while it's related, it's not quite the same point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085372871

From duke at openjdk.org  Mon May 12 20:21:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 20:21:51 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: 

On Mon, 12 May 2025 15:57:35 GMT, Alan Bateman  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/module-info.java line 160:
> 
>> 158:  *       will always be opened read-write (see {@code "accessMode"}
>> 159:  *       below), regardless of whether the underlying ZIP already existed or
>> 160:  *       not.
> 
> In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist.
> 
> For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system.

Is this comment just agreeing with the proposed behaviour stated here?

At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests).

The only allowed access mode options with "create" are "readWrite" or , and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085381219

From jpai at openjdk.org  Tue May 13 02:11:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 02:11:03 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 12 May 2025 10:34:37 GMT, Markus KARG  wrote:

>> Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?
>
> We could also simply include it in the PR for https://bugs.openjdk.org/browse/JDK-8356679 to reduce organizational overhead.

Hello Markus, it's OK to do this text change as part of JDK-8356679. Like Roger noted in the corresponding core-libs-dev mailing list, it would be good to do the 8356679 changes in smaller pieces and include this change in one of those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2085794320

From alanb at openjdk.org  Tue May 13 06:14:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 06:14:51 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
 
Message-ID: 

On Mon, 12 May 2025 20:19:43 GMT, David Beaumont  wrote:

>> src/jdk.zipfs/share/classes/module-info.java line 160:
>> 
>>> 158:  *       will always be opened read-write (see {@code "accessMode"}
>>> 159:  *       below), regardless of whether the underlying ZIP already existed or
>>> 160:  *       not.
>> 
>> In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist.
>> 
>> For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system.
>
> Is this comment just agreeing with the proposed behaviour stated here?
> 
> At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests).
> 
> The only allowed access mode options with "create" are "readWrite" or , and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured.

I agree that read-only && create is a combination to be rejected.  My comment is about the update to the description of the "create" option. It's the first row in the table and the changes suggests that it is forcing the file system to be read-write. I think the wording for the "readOnly" option is sufficient, meaning just one place to document the conflict between these two options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085993836

From alanb at openjdk.org  Tue May 13 06:23:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 06:23:51 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix)
In-Reply-To: 
References: 
Message-ID: <4LoLaYqZD5vjmpIzegO_EmcXjDu_GrNPYTbHMYJrKxs=.95967344-2a79-42f2-805e-612484dadb45@github.com>

On Mon, 12 May 2025 19:36:22 GMT, Brian Burkhalter  wrote:

> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.

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

> 67:         try {
> 68:             Files.copy(leaf, Path.of("junk"));
> 69:         } catch (NoSuchFileException expected) {

FYI you can use assertThrows to avoid the try-catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2086006015

From alanb at openjdk.org  Tue May 13 06:39:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 06:39:53 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix)
In-Reply-To: 
References: 
Message-ID: <7qBL4opXQx81_bb5QX4h1gApzqTwCUg1c_IeyjUxG3o=.91d67b55-90cb-4fcc-957a-d57809808bba@github.com>

On Mon, 12 May 2025 19:36:22 GMT, Brian Burkhalter  wrote:

> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.

The update to UnixFileSystem.copy looks good. 

What about move? It looks like rename can fail with ENOTDIR. It looks like we'd want to map that to NoSuchFileException when a component in the source is not a directory, less clear for the target file. But maybe this is why you decided to not change it? (Not changing is okay).

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

> 25:  * @bug 8356678
> 26:  * @requires (os.family != "windows")
> 27:  * @summary Test behavior of Files methods for regular file "foo/bar"

I think the summary needs to say that it tests file operations when a component in the path is a regular rather than a directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/25191#issuecomment-2875219945
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2086028193

From jpai at openjdk.org  Tue May 13 12:35:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 12:35:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 147:

> 145:     // this could exist somewhere common, but if it's definitely never going to
> 146:     // be shared, it could be made public here.
> 147:     private enum AccessMode {

Hello David, I think having it `private` is fine and in fact more appropriate. I would suggest removing the comment though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086711632

From jpai at openjdk.org  Tue May 13 12:46:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 12:46:59 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/module-info.java line 277:

> 275:  *   
> 276:  *       A value defining the desired read/write access mode of the file system
> 277:  *       (either read-write or read-only).

This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system.

Perhaps we could reword this to something like:

>
> A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086732377

From jpai at openjdk.org  Tue May 13 13:52:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 13:52:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167:

> 165:                     return null;
> 166:                 }
> 167:                 case String label when READ_WRITE.label.equals(label) -> {

I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler:


case "readWrite" -> {
   return READ_WRITE;
}
case "readOnly" -> {
   return READ_ONLY;
}

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 174:

> 172:                 }
> 173:                 default -> {
> 174:                 }

Since we don't allow for any other value, I think moving the `throw new IllegalArgumentException` from outside of the switch into this `default` case might be suitable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086881780
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086877658

From jpai at openjdk.org  Tue May 13 13:59:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 13:59:52 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 160:

> 158: 
> 159:         // Parses the file system permission from an environmental parameter. While
> 160:         // the FileSystemAccessMode is private, we don't need to check if it was

The second sentence perhaps is a leftover? I don't see any `FileSystemAccessMode` type. I think it would be better to remove that second sentence altogether. The rest of the comment looks good and clearly states what this method does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086897450

From bpb at openjdk.org  Tue May 13 15:24:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 15:24:13 GMT
Subject: Integrated: 8351415: (fs) Path::toAbsolutePath should specify if an
 absolute path has a root component
In-Reply-To: 
References: 
Message-ID: <3x0PmDBqmGGGGBd3y4BBG2cda92Ah5ilUCLfgPWK0kk=.92f91b23-60f8-4be8-acad-a6f12fac4f5c@github.com>

On Fri, 9 May 2025 22:44:04 GMT, Brian Burkhalter  wrote:

> Add a sentence to the specification of `Path::toAbsolutePath` indicating that the root component of the absolute path derived from a `Path` associated with the default provider is non-`null`.

This pull request has now been integrated.

Changeset: 0318e495
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/0318e49500edb129159030589472089ec21f2f58
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component

Reviewed-by: alanb

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

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

From jpai at openjdk.org  Tue May 13 16:28:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 16:28:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208:

> 206:         boolean shouldCreate = isTrue(env, "create");
> 207:         if (shouldCreate && forceReadOnly) {
> 208:             throw new IllegalArgumentException(

Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`.

So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2087216326

From alanb at openjdk.org  Tue May 13 16:39:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 16:39:51 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>

On Tue, 13 May 2025 16:26:31 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208:
> 
>> 206:         boolean shouldCreate = isTrue(env, "create");
>> 207:         if (shouldCreate && forceReadOnly) {
>> 208:             throw new IllegalArgumentException(
> 
> Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`.
> 
> So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API.

I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2087233643

From naoto at openjdk.org  Tue May 13 18:12:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 May 2025 18:12:35 GMT
Subject: RFR: 8356822: Refactor HTML anchor tags to javadoc in Charset
Message-ID: 

Simple cleanup

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

Commit messages:
 - initial commit

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

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

From iris at openjdk.org  Tue May 13 18:27:54 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 13 May 2025 18:27:54 GMT
Subject: RFR: 8356822: Refactor HTML anchor tags to javadoc in Charset
In-Reply-To: 
References: 
Message-ID: <3iQ7ZdZ1v8HhXISew6JWgfQkY8tb5A1lcd8NgrUH4Fw=.6ad9a6c8-9ceb-49bd-875c-02fcaf5045ae@github.com>

On Tue, 13 May 2025 18:07:28 GMT, Naoto Sato  wrote:

> Simple cleanup

Nice.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25216#pullrequestreview-2837741004

From bpb at openjdk.org  Tue May 13 20:32:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 20:32:54 GMT
Subject: RFR: 8353923: (fs) Further improve performance of URI -> Path
 conversion (win) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 00:41:11 GMT, Brian Burkhalter  wrote:

>> If the path portion of a `URI` permits, then simply replace all `'\'` with `'/'` instead of completely parsing the path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353923: Add PathOfURI benchmark

`continue;`

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

PR Comment: https://git.openjdk.org/jdk/pull/24638#issuecomment-2877868122

From bpb at openjdk.org  Tue May 13 23:53:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 23:53:38 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v2]
In-Reply-To: 
References: 
Message-ID: 

> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.

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

  8356678: Add more checks in copy and move; beef up test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25191/files
  - new: https://git.openjdk.org/jdk/pull/25191/files/3c90a689..fce26e50

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

  Stats: 95 lines in 2 files changed: 70 ins; 4 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25191.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25191/head:pull/25191

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

From bpb at openjdk.org  Tue May 13 23:53:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 23:53:38 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix)
In-Reply-To: <7qBL4opXQx81_bb5QX4h1gApzqTwCUg1c_IeyjUxG3o=.91d67b55-90cb-4fcc-957a-d57809808bba@github.com>
References: 
 <7qBL4opXQx81_bb5QX4h1gApzqTwCUg1c_IeyjUxG3o=.91d67b55-90cb-4fcc-957a-d57809808bba@github.com>
Message-ID: 

On Tue, 13 May 2025 06:35:56 GMT, Alan Bateman  wrote:

> What about move?

I hope to have fixed this in fce26e5. The test coverage is substantially improved and the implementation changed to fix any failures discovered.

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

PR Comment: https://git.openjdk.org/jdk/pull/25191#issuecomment-2878203179

From bpb at openjdk.org  Tue May 13 23:53:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 23:53:38 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v2]
In-Reply-To: <7qBL4opXQx81_bb5QX4h1gApzqTwCUg1c_IeyjUxG3o=.91d67b55-90cb-4fcc-957a-d57809808bba@github.com>
References: 
 <7qBL4opXQx81_bb5QX4h1gApzqTwCUg1c_IeyjUxG3o=.91d67b55-90cb-4fcc-957a-d57809808bba@github.com>
Message-ID: 

On Tue, 13 May 2025 06:37:18 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356678: Add more checks in copy and move; beef up test
>
> test/jdk/java/nio/file/Files/NotADirectory.java line 27:
> 
>> 25:  * @bug 8356678
>> 26:  * @requires (os.family != "windows")
>> 27:  * @summary Test behavior of Files methods for regular file "foo/bar"
> 
> I think the summary needs to say that it tests file operations when a component in the path is a regular rather than a directory.

Improved in fce26e5.

> test/jdk/java/nio/file/Files/NotADirectory.java line 69:
> 
>> 67:         try {
>> 68:             Files.copy(leaf, Path.of("junk"));
>> 69:         } catch (NoSuchFileException expected) {
> 
> FYI you can use assertThrows to avoid the try-catch.

Thanks. I know about that but didn't use it anyway. Fixed in fce26e5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2087780124
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2087779984

From bpb at openjdk.org  Wed May 14 02:18:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 02:18:51 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 23:53:38 GMT, Brian Burkhalter  wrote:

>> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356678: Add more checks in copy and move; beef up test

The `jdk_nio` tests pass on Linux and macOS for fce26e5.

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

PR Comment: https://git.openjdk.org/jdk/pull/25191#issuecomment-2878436939

From alanb at openjdk.org  Wed May 14 05:42:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 May 2025 05:42:52 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 23:53:38 GMT, Brian Burkhalter  wrote:

>> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356678: Add more checks in copy and move; beef up test

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 487:

> 485:             if (x.errno() == ENOTDIR) {
> 486:                 x.setError(ENOENT);
> 487:             }

This is the mkdir to create the target so I don't think we should change this as it would be very confusing to see NoSuchFileException here.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 638:

> 636:                 if (x.errno() == ENOTDIR) {
> 637:                     x.setError(ENOENT);
> 638:                 }

This is also the target so I don't think this should be changed.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 829:

> 827:                         x.errorString());
> 828:                 } else if (x.errno() == ENOTDIR) {
> 829:                     x.setError(ENOENT);

This is rename where the issue might be the source or target path. So I think we have to drop this change too.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 904:

> 902:                 if (x.errno() == ENOTDIR) {
> 903:                     x.setError(ENOENT);
> 904:                 }

This is also a rename so need to drop this change too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2088076276
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2088076710
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2088077437
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2088078923

From jpai at openjdk.org  Wed May 14 06:53:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 May 2025 06:53:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
 <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
Message-ID: 

On Tue, 13 May 2025 16:37:12 GMT, Alan Bateman  wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208:
>> 
>>> 206:         boolean shouldCreate = isTrue(env, "create");
>>> 207:         if (shouldCreate && forceReadOnly) {
>>> 208:             throw new IllegalArgumentException(
>> 
>> Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`.
>> 
>> So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API.
>
> I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise.

I'll file an issue for this today, shortly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2088183284

From alanb at openjdk.org  Wed May 14 07:46:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 May 2025 07:46:50 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
 <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
 
Message-ID: 

On Wed, 14 May 2025 06:51:14 GMT, Jaikiran Pai  wrote:

>> I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise.
>
> I'll file an issue for this today, shortly.

I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2088288990

From azeller at openjdk.org  Wed May 14 08:04:35 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 14 May 2025 08:04:35 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling setsockopt
 in Net.joinOrDrop
Message-ID: 

On AIX we have sporadic EAGAIN errors when calling setsockopt. This is undocumented, but has been seen in tests. 
Further test did show that it might not be enough to only try it once again. In our daily test environment we have seen no more unexpected exceptions when we retried 3 times.

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

Commit messages:
 - Retry 3 times
 - Update copyright
 - JDK-8354530 : AIX: sporadic unexpected errno when calling setsockopt in Net.joinOrDrop.

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

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

From alanb at openjdk.org  Wed May 14 08:28:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 May 2025 08:28:56 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop
In-Reply-To: 
References: 
Message-ID: 

On Fri, 2 May 2025 08:13:46 GMT, Arno Zeller  wrote:

> On AIX we have sporadic EAGAIN errors when calling setsockopt. This is undocumented, but has been seen in tests. 
> Further test did show that it might not be enough to only try it once again. In our daily test environment we have seen no more unexpected exceptions when we retried 3 times.

src/java.base/unix/native/libnio/ch/Net.c line 675:

> 673: #endif
> 674: #ifdef _AIX
> 675:     // workaround AIX bug where IP_ADD_MEMBERSHIP fails intermittently sometimes even more than one time...

Adding a retry loop is okay, we have to retry on macOS too. Can you drop "even more than one time..." from the comment as it doesn't help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24996#discussion_r2088368750

From azeller at openjdk.org  Wed May 14 09:41:33 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 14 May 2025 09:41:33 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
Message-ID: 

> On AIX we have sporadic EAGAIN errors when calling setsockopt. This is undocumented, but has been seen in tests. 
> Further test did show that it might not be enough to only try it once again. In our daily test environment we have seen no more unexpected exceptions when we retried 3 times.

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

  Improve comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24996/files
  - new: https://git.openjdk.org/jdk/pull/24996/files/a5caac41..b33fd1f1

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

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

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

From azeller at openjdk.org  Wed May 14 09:41:33 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 14 May 2025 09:41:33 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 May 2025 08:26:24 GMT, Alan Bateman  wrote:

>> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment.
>
> src/java.base/unix/native/libnio/ch/Net.c line 675:
> 
>> 673: #endif
>> 674: #ifdef _AIX
>> 675:     // workaround AIX bug where IP_ADD_MEMBERSHIP fails intermittently sometimes even more than one time...
> 
> Adding a retry loop is okay, we have to retry on macOS too. Can you drop "even more than one time..." from the comment as it doesn't help.

Of course! I dropped the end of the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24996#discussion_r2088516917

From alanb at openjdk.org  Wed May 14 12:16:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 May 2025 12:16:54 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 May 2025 09:41:33 GMT, Arno Zeller  wrote:

>> On AIX we have sporadic EAGAIN errors when calling setsockopt. This is undocumented, but has been seen in tests. 
>> Further test did show that it might not be enough to only try it once again. In our daily test environment we have seen no more unexpected exceptions when we retried 3 times.
>
> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment.

Looks okay, I assume you've update the copyright header before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24996#pullrequestreview-2839949988

From clanger at openjdk.org  Wed May 14 13:02:53 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 14 May 2025 13:02:53 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 May 2025 09:41:33 GMT, Arno Zeller  wrote:

>> On AIX we have sporadic EAGAIN errors when calling setsockopt. This is undocumented, but has been seen in tests. 
>> Further test did show that it might not be enough to only try it once again. In our daily test environment we have seen no more unexpected exceptions when we retried 3 times.
>
> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment.

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24996#pullrequestreview-2840092794

From stuefe at openjdk.org  Wed May 14 13:34:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 14 May 2025 13:34:54 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 May 2025 09:41:33 GMT, Arno Zeller  wrote:

>> On AIX we have sporadic EAGAIN errors when calling setsockopt. This is undocumented, but has been seen in tests. 
>> Further test did show that it might not be enough to only try it once again. In our daily test environment we have seen no more unexpected exceptions when we retried 3 times.
>
> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment.

src/java.base/unix/native/libnio/ch/Net.c line 683:

> 681:         }
> 682:     }
> 683: #endif

drive-by comment, would it not make sense to then wait some milliseconds before the next try?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24996#discussion_r2088960401

From ihse at openjdk.org  Wed May 14 14:28:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:28:10 GMT
Subject: RFR: 8356977: UTF-8 cleanups
Message-ID: 

I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

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

Commit messages:
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

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

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

From lancea at openjdk.org  Wed May 14 16:46:00 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 May 2025 16:46:00 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

Thank. you David for your work here

A few comments on a quick pass in addition to those from Alan & Jai

The copyright will also need to be updated

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 95:

> 93: 
> 94:     private static final Set DEFAULT_PERMISSIONS =
> 95:         PosixFilePermissions.fromString("rwxrwxrwx");

I am not convinced this needs to be changed as it becomes a  personal style preference

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 113:

> 111:     final ZipCoder zc;
> 112:     private final ZipPath rootdir;
> 113:     // Start readOnly (safe mode) and maybe reset at end of initialization.

maybe -> may be

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 219:

> 217:             assertFalse(fs.isReadOnly());
> 218:             if (!"Default version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) {
> 219:                 throw new RuntimeException("unexpected file content");

could also consider

fail("unexpected file content");

test/jdk/jdk/nio/zipfs/TestPosix.java line 434:

> 432:         createTestZipFile(ZIP_FILE, ENV_DEFAULT).close();
> 433:         // check entries on zipfs with default options
> 434:         try (FileSystem zip = FileSystems.newFileSystem(ZIP_FILE, ENV_DEFAULT)) {

This tests an empty Map and should still be a test as it is different from ENV_READ_ONLY

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

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2840686940
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089239326
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089240538
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089339910
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089344316

From lancea at openjdk.org  Wed May 14 17:06:55 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 May 2025 17:06:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: 

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 207:

> 205:                         Map.of("create", true, "accessMode", "badValue")));
> 206:     }
> 207: 

You could simplify the above tests using a DataProvider similar to

@DataProvider(name = "zipfsMap")
protected Object[][] zipfsMap() {
    return new Object[][]{
            {Map.of(), NoSuchFileException.class},
            {Map.of("accessMode", "readOnly"), NoSuchFileException.class},
            {Map.of("accessMode", "readWrite"),  NoSuchFileException.class},
            {Map.of("create", true, "accessMode", "readOnly"),  IllegalArgumentException.class},
            {Map.of("create", true, "accessMode", "badValue"),  IllegalArgumentException.class},
    };
@Test(dataProvider = "zipfsMap?)
public void testZipFSCreationException(Map env, Class exception) throws Exception {
       assertThrows(exception, () -> FileSystems.newFileSystem(noSuchZip, env));
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089378491

From bpb at openjdk.org  Wed May 14 17:21:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 17:21:13 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v3]
In-Reply-To: 
References: 
Message-ID: 

> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.

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

  8356678: Revert some of the ENOTDIR changes and update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25191/files
  - new: https://git.openjdk.org/jdk/pull/25191/files/fce26e50..0908e753

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

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

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

From bpb at openjdk.org  Wed May 14 17:21:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 17:21:13 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v2]
In-Reply-To: 
References: 
 
Message-ID: <-Ix-mg77N4K-mG34WclP8Aufrkx_iY7UODoLrc-myjw=.2106120e-0669-4b5e-8b42-836a7dd9adcc@github.com>

On Tue, 13 May 2025 23:53:38 GMT, Brian Burkhalter  wrote:

>> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356678: Add more checks in copy and move; beef up test

All `jdk_nio` tests pass with 0908e75 on Linux and macOS.

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

PR Comment: https://git.openjdk.org/jdk/pull/25191#issuecomment-2880981158

From bpb at openjdk.org  Wed May 14 17:21:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 17:21:14 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 14 May 2025 05:37:39 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356678: Add more checks in copy and move; beef up test
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 487:
> 
>> 485:             if (x.errno() == ENOTDIR) {
>> 486:                 x.setError(ENOENT);
>> 487:             }
> 
> This is the mkdir to create the target so I don't think we should change this as it would be very confusing to see NoSuchFileException here.

Reverted in 0908e75.

> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 638:
> 
>> 636:                 if (x.errno() == ENOTDIR) {
>> 637:                     x.setError(ENOENT);
>> 638:                 }
> 
> This is also the target so I don't think this should be changed.

Reverted in 0908e75.

> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 829:
> 
>> 827:                         x.errorString());
>> 828:                 } else if (x.errno() == ENOTDIR) {
>> 829:                     x.setError(ENOENT);
> 
> This is rename where the issue might be the source or target path. So I think we have to drop this change too.

Reverted in 0908e75.

> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 904:
> 
>> 902:                 if (x.errno() == ENOTDIR) {
>> 903:                     x.setError(ENOENT);
>> 904:                 }
> 
> This is also a rename so need to drop this change too.

Reverted in 0908e75.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2089398071
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2089398290
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2089398500
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2089398714

From alanb at openjdk.org  Wed May 14 17:31:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 May 2025 17:31:53 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 May 2025 17:21:13 GMT, Brian Burkhalter  wrote:

>> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356678: Revert some of the ENOTDIR changes and update test

Latest version looks good, just a confusing summary in the NotADirectory test.

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

> 25:  * @bug 8356678
> 26:  * @requires (os.family != "windows")
> 27:  * @summary Test files operations when a path component is not a regular file

I assume you meant to say "when a path component is not a directory".

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25191#pullrequestreview-2840977470
PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2089415433

From bpb at openjdk.org  Wed May 14 17:51:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 17:51:34 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v4]
In-Reply-To: 
References: 
Message-ID: <4b6WBp7w4lO9nqX2IHkFCuuk0iOErZ2EY3Ntf0r0H-E=.55f80846-0df6-4d42-8b55-7342d1eccc7a@github.com>

> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.

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

  8356678: Improve test summary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25191/files
  - new: https://git.openjdk.org/jdk/pull/25191/files/0908e753..2344b7da

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

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

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

From bpb at openjdk.org  Wed May 14 17:51:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 17:51:34 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 14 May 2025 17:28:41 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8356678: Revert some of the ENOTDIR changes and update test
>
> test/jdk/java/nio/file/Files/NotADirectory.java line 27:
> 
>> 25:  * @bug 8356678
>> 26:  * @requires (os.family != "windows")
>> 27:  * @summary Test files operations when a path component is not a regular file
> 
> I assume you meant to say "when a path component is not a directory".

Yes. So changed in 2344b7d.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25191#discussion_r2089447347

From alanb at openjdk.org  Wed May 14 18:08:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 May 2025 18:08:56 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v4]
In-Reply-To: <4b6WBp7w4lO9nqX2IHkFCuuk0iOErZ2EY3Ntf0r0H-E=.55f80846-0df6-4d42-8b55-7342d1eccc7a@github.com>
References: 
 <4b6WBp7w4lO9nqX2IHkFCuuk0iOErZ2EY3Ntf0r0H-E=.55f80846-0df6-4d42-8b55-7342d1eccc7a@github.com>
Message-ID: <5MK7ezLROewso5n4DJzapHmBEP0EDY7BKcg0uE8Dzlk=.7a808d85-9307-48e3-9071-cb97ec3faba1@github.com>

On Wed, 14 May 2025 17:51:34 GMT, Brian Burkhalter  wrote:

>> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356678: Improve test summary

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25191#pullrequestreview-2841080893

From azeller at openjdk.org  Wed May 14 19:01:52 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 14 May 2025 19:01:52 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 14 May 2025 13:32:03 GMT, Thomas Stuefe  wrote:

>> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment.
>
> src/java.base/unix/native/libnio/ch/Net.c line 683:
> 
>> 681:         }
>> 682:     }
>> 683: #endif
> 
> drive-by comment, would it not make sense to then wait some milliseconds before the next try?

I am unsure if this would be better - I have seen test failing about 2-3 times a day in our nightly tests. With a direct retry I have seen tests failing only every 3-5 days - with a second retry it failed only one time in 3 weeks. Therefore I decided to go for 3 retries without waiting. 
Another possibility would be to wait for an increasing number of milliseconds - like 0, 10, 20ms in each try. But I am not sure if this is worth it.
What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24996#discussion_r2089555110

From liach at openjdk.org  Thu May 15 01:03:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 May 2025 01:03:50 GMT
Subject: RFR: 8356822: Refactor HTML anchor tags to javadoc in Charset
In-Reply-To: 
References: 
Message-ID: 

On Tue, 13 May 2025 18:07:28 GMT, Naoto Sato  wrote:

> Simple cleanup

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25216#pullrequestreview-2841847345

From stuefe at openjdk.org  Thu May 15 05:00:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 May 2025 05:00:51 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <7iFu-iOTXmTc71xWMhZIhZzrgUjmujENXt4rYY1XWy4=.62f6cc41-6185-47c5-93f4-728921051597@github.com>

On Wed, 14 May 2025 18:59:31 GMT, Arno Zeller  wrote:

>> src/java.base/unix/native/libnio/ch/Net.c line 683:
>> 
>>> 681:         }
>>> 682:     }
>>> 683: #endif
>> 
>> drive-by comment, would it not make sense to then wait some milliseconds before the next try?
>
> I am unsure if this would be better - I have seen test failing about 2-3 times a day in our nightly tests. With a direct retry I have seen tests failing only every 3-5 days - with a second retry it failed only one time in 3 weeks. Therefore I decided to go for 3 retries without waiting. 
> Another possibility would be to wait for an increasing number of milliseconds - like 0, 10, 20ms in each try. But I am not sure if this is worth it.
> What do you think?

Do we know what the underlying problem is? We are waiting on the kernel? Or something outside?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24996#discussion_r2090248101

From stuefe at openjdk.org  Thu May 15 05:00:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 May 2025 05:00:51 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: <7iFu-iOTXmTc71xWMhZIhZzrgUjmujENXt4rYY1XWy4=.62f6cc41-6185-47c5-93f4-728921051597@github.com>
References: 
 
 
 
 <7iFu-iOTXmTc71xWMhZIhZzrgUjmujENXt4rYY1XWy4=.62f6cc41-6185-47c5-93f4-728921051597@github.com>
Message-ID: 

On Thu, 15 May 2025 04:58:00 GMT, Thomas Stuefe  wrote:

>> I am unsure if this would be better - I have seen test failing about 2-3 times a day in our nightly tests. With a direct retry I have seen tests failing only every 3-5 days - with a second retry it failed only one time in 3 weeks. Therefore I decided to go for 3 retries without waiting. 
>> Another possibility would be to wait for an increasing number of milliseconds - like 0, 10, 20ms in each try. But I am not sure if this is worth it.
>> What do you think?
>
> Do we know what the underlying problem is? We are waiting on the kernel? Or something outside?

(If you want to push this, go ahead; I don't want to hold up this patch)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24996#discussion_r2090248515

From cstein at openjdk.org  Thu May 15 06:00:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 15 May 2025 06:00:51 GMT
Subject: RFR: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix) [v4]
In-Reply-To: <4b6WBp7w4lO9nqX2IHkFCuuk0iOErZ2EY3Ntf0r0H-E=.55f80846-0df6-4d42-8b55-7342d1eccc7a@github.com>
References: 
 <4b6WBp7w4lO9nqX2IHkFCuuk0iOErZ2EY3Ntf0r0H-E=.55f80846-0df6-4d42-8b55-7342d1eccc7a@github.com>
Message-ID: <9Rd9-KYs53vRJxGw-gOE-C-1VJc_vGRyZmnpi81TYQc=.344e9cfc-f01e-41a7-ae12-84a65e74bf47@github.com>

On Wed, 14 May 2025 17:51:34 GMT, Brian Burkhalter  wrote:

>> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356678: Improve test summary

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25191#pullrequestreview-2842349376

From azeller at openjdk.org  Thu May 15 07:26:55 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 15 May 2025 07:26:55 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
 
 
 <7iFu-iOTXmTc71xWMhZIhZzrgUjmujENXt4rYY1XWy4=.62f6cc41-6185-47c5-93f4-728921051597@github.com>
 
Message-ID: 

On Thu, 15 May 2025 04:58:34 GMT, Thomas Stuefe  wrote:

>> Do we know what the underlying problem is? We are waiting on the kernel? Or something outside?
>
> (If you want to push this, go ahead; I don't want to hold up this patch)

> Do we know what the underlying problem is? We are waiting on the kernel? Or something outside?
I have no further information why this errno is returned, only that EAGAIN ist not specified by AIX as an errno for  setsockopt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24996#discussion_r2090471565

From duke at openjdk.org  Thu May 15 07:32:52 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 07:32:52 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 May 2025 09:41:33 GMT, Arno Zeller  wrote:

>> On AIX we have sporadic EAGAIN errors when calling setsockopt. This is undocumented, but has been seen in tests. 
>> Further test did show that it might not be enough to only try it once again. In our daily test environment we have seen no more unexpected exceptions when we retried 3 times.
>
> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment.

@ArnoZeller 
Your change (at version b33fd1f1f6f9fbf42052e8e4675e3f372ecd61ae) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24996#issuecomment-2882846117

From azeller at openjdk.org  Thu May 15 07:32:52 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 15 May 2025 07:32:52 GMT
Subject: RFR: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop [v2]
In-Reply-To: 
References: 
 
 
 
 <7iFu-iOTXmTc71xWMhZIhZzrgUjmujENXt4rYY1XWy4=.62f6cc41-6185-47c5-93f4-728921051597@github.com>
 
 
Message-ID: 

On Thu, 15 May 2025 07:24:16 GMT, Arno Zeller  wrote:

>> (If you want to push this, go ahead; I don't want to hold up this patch)
>
>> Do we know what the underlying problem is? We are waiting on the kernel? Or something outside?
> 
> I have no further information why this errno is returned, only that EAGAIN ist not specified by AIX as an errno for  setsockopt.

> (If you want to push this, go ahead; I don't want to hold up this patch)

Thanks - I will integrate it now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24996#discussion_r2090479219

From azeller at openjdk.org  Thu May 15 07:53:05 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 15 May 2025 07:53:05 GMT
Subject: Integrated: 8354530: AIX: sporadic unexpected errno when calling
 setsockopt in Net.joinOrDrop
In-Reply-To: 
References: 
Message-ID: 

On Fri, 2 May 2025 08:13:46 GMT, Arno Zeller  wrote:

> On AIX we have sporadic EAGAIN errors when calling setsockopt. This is undocumented, but has been seen in tests. 
> Further test did show that it might not be enough to only try it once again. In our daily test environment we have seen no more unexpected exceptions when we retried 3 times.

This pull request has now been integrated.

Changeset: dc881ee3
Author:    Arno Zeller 
Committer: Christoph Langer 
URL:       https://git.openjdk.org/jdk/commit/dc881ee36900bc12bea9616a6078a1f3266c183d
Stats:     11 lines in 1 file changed: 10 ins; 0 del; 1 mod

8354530: AIX: sporadic unexpected errno when calling setsockopt in Net.joinOrDrop

Reviewed-by: alanb, clanger

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

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

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

After an offline discussion, we agreed to wait a bit with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Thu May 15 14:50:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 May 2025 14:50:03 GMT
Subject: Integrated: 8356678: (fs) Files.readAttributes should map ENOTDIR to
 NoSuchFileException where possible (unix)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 May 2025 19:36:22 GMT, Brian Burkhalter  wrote:

> Treat `ENOTDIR` as causing a `NoSuchFileException` instead of a `FileSystemExcception` in some places in order to handle cases such as a regular file named, for example, `foo/bar`.

This pull request has now been integrated.

Changeset: 3df8ca1e
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/3df8ca1ebaf3539363efd569ba9487f5d985117d
Stats:     175 lines in 4 files changed: 171 ins; 1 del; 3 mod

8356678: (fs) Files.readAttributes should map ENOTDIR to NoSuchFileException where possible (unix)

Reviewed-by: alanb, cstein

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

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

From naoto at openjdk.org  Thu May 15 16:17:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 16:17:03 GMT
Subject: Integrated: 8356822: Refactor HTML anchor tags to javadoc in Charset
In-Reply-To: 
References: 
Message-ID: 

On Tue, 13 May 2025 18:07:28 GMT, Naoto Sato  wrote:

> Simple cleanup

This pull request has now been integrated.

Changeset: e056bbec
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/e056bbec928e3914a3b5cd14753406619e187178
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8356822: Refactor HTML anchor tags to javadoc in Charset

Reviewed-by: iris, liach

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

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

From naoto at openjdk.org  Thu May 15 16:17:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 16:17:03 GMT
Subject: RFR: 8356822: Refactor HTML anchor tags to javadoc in Charset
In-Reply-To: 
References: 
Message-ID: <2rRCYVSaUgfp-DM-EJGp_ZCO51UAfPSAioyhjiHw6JU=.9eb77f03-8693-4fff-9932-a16fb151f7d7@github.com>

On Tue, 13 May 2025 18:07:28 GMT, Naoto Sato  wrote:

> Simple cleanup

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25216#issuecomment-2884375922

From duke at openjdk.org  Thu May 15 17:18:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:18:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: 

On Tue, 13 May 2025 12:32:56 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 147:
> 
>> 145:     // this could exist somewhere common, but if it's definitely never going to
>> 146:     // be shared, it could be made public here.
>> 147:     private enum AccessMode {
> 
> Hello David, I think having it `private` is fine and in fact more appropriate. I would suggest removing the comment though.

Done. And if it's not getting made visible (i.e. values are always strings) I can simplify things too.

> src/jdk.zipfs/share/classes/module-info.java line 277:
> 
>> 275:  *   
>> 276:  *       A value defining the desired read/write access mode of the file system
>> 277:  *       (either read-write or read-only).
> 
> This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system.
> 
> Perhaps we could reword this to something like:
> 
>>
>> A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access.

Yeah, I tried to distinguish the accessMode flags (for which there are 3 states, ro, rw, n/a) and the final state of the file system from fs.isReadOnly(). Hence using `...` for whenever the actually resulting state is mentioned. I guess it wasn't clear enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091645807
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091649006

From duke at openjdk.org  Thu May 15 17:26:53 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:26:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: 

On Tue, 13 May 2025 13:48:32 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 174:
> 
>> 172:                 }
>> 173:                 default -> {
>> 174:                 }
> 
> Since we don't allow for any other value, I think moving the `throw new IllegalArgumentException` from outside of the switch into this `default` case might be suitable.

I rewrote to avoid the switch now there's no way it needs to cope with being the enum value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091660167

From duke at openjdk.org  Thu May 15 17:32:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:32:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: 

On Tue, 13 May 2025 13:56:34 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 160:
> 
>> 158: 
>> 159:         // Parses the file system permission from an environmental parameter. While
>> 160:         // the FileSystemAccessMode is private, we don't need to check if it was
> 
> The second sentence perhaps is a leftover? I don't see any `FileSystemAccessMode` type. I think it would be better to remove that second sentence altogether. The rest of the comment looks good and clearly states what this method does.

Done.

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167:
> 
>> 165:                     return null;
>> 166:                 }
>> 167:                 case String label when READ_WRITE.label.equals(label) -> {
> 
> I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler:
> 
> 
> case "readWrite" -> {
>    return READ_WRITE;
> }
> case "readOnly" -> {
>    return READ_ONLY;
> }

Or just an if :)

The reason for the new style was the "need" for the "String label when" qualifier, which I don't actually need because String.equals(xx) copes with being given non-strings fine. You can't use the syntax you suggested in the new switch since "value" isn't a String.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091667975
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091665729

From duke at openjdk.org  Thu May 15 17:32:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:32:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
 <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
 
 
Message-ID: 

On Wed, 14 May 2025 07:43:54 GMT, Alan Bateman  wrote:

>> I'll file an issue for this today, shortly.
>
> I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already.

So does this mean the code is good as-is now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091670125

From duke at openjdk.org  Thu May 15 17:39:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:39:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: <_fOwfCN-skLDUctxfNIhNVFJB6Q6-RWR7ohRsKi0Yck=.5f156736-e8df-4735-b8b6-fc2cb96ad6d0@github.com>

On Wed, 14 May 2025 15:40:41 GMT, Lance Andersen  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 95:
> 
>> 93: 
>> 94:     private static final Set DEFAULT_PERMISSIONS =
>> 95:         PosixFilePermissions.fromString("rwxrwxrwx");
> 
> I am not convinced this needs to be changed as it becomes a  personal style preference

Possibly not, but it is only used in one place, and anyone reading the code now has the comment saying "If not specified in env, it will return 777." three lines away from the code that uses "rwxrwxrwx" instead of nearly 300.

Plus, there isn't now a *mutable* static final constant which could be accidentally leaked and mutated in the future.

Yes, it's personal preference to a degree, but I feel this is a small, but non-zero, improvement in maintainability, and I would ask someone to do this if I were reviewing a change which added this to the code.

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 113:
> 
>> 111:     final ZipCoder zc;
>> 112:     private final ZipPath rootdir;
>> 113:     // Start readOnly (safe mode) and maybe reset at end of initialization.
> 
> maybe -> may be

Both work. It "may be reset", but also "maybe we will reset it". I reworded slightly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091678054
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091679779

From duke at openjdk.org  Thu May 15 17:42:52 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:42:52 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: 

On Wed, 14 May 2025 16:39:18 GMT, Lance Andersen  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 219:
> 
>> 217:             assertFalse(fs.isReadOnly());
>> 218:             if (!"Default version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) {
>> 219:                 throw new RuntimeException("unexpected file content");
> 
> could also consider
> 
> fail("unexpected file content");

Oh thanks for spotting!
That's a hangover from when it was in the old-style test class (ZipFSTester or whatever it's called).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091684373

From jpai at openjdk.org  Thu May 15 17:45:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 May 2025 17:45:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
 <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
 
 
 
Message-ID: 

On Thu, 15 May 2025 17:30:35 GMT, David Beaumont  wrote:

>> I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already.
>
> So does this mean the code is good as-is now?

Hello David, yes it's fine to throw `IllegalArgumentException` from here. The specification of `FileSystemProvider.newFileSystem(...)` APIs will be updated in a separate PR to specify the `IllegalArgumentException` that gets thrown. With that, the zipfs provider implementation will conform to the specification and applications are then expected to deal with the `IllegalArgumentException` caused by an incorrect environment property value that was passed during the filesystem construction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091688623

From duke at openjdk.org  Thu May 15 17:54:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:54:51 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
 
 
Message-ID: 

On Tue, 13 May 2025 06:12:11 GMT, Alan Bateman  wrote:

>> Is this comment just agreeing with the proposed behaviour stated here?
>> 
>> At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests).
>> 
>> The only allowed access mode options with "create" are "readWrite" or , and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured.
>
> I agree that read-only && create is a combination to be rejected.  My comment is about the update to the description of the "create" option. It's the first row in the table and the changes suggests that it is forcing the file system to be read-write. I think the wording for the "readOnly" option is sufficient, meaning just one place to document the conflict between these two options.

Restored the original comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091701008

From duke at openjdk.org  Thu May 15 17:54:53 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:54:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
 
Message-ID: 

On Mon, 12 May 2025 20:12:53 GMT, David Beaumont  wrote:

>> src/jdk.zipfs/share/classes/module-info.java line 281:
>> 
>>> 279:  *       Even if a zip file system is writable ({@code fs.isReadOnly() == false}),
>>> 280:  *       this says nothing about whether individual files can be created or
>>> 281:  *       modified, simply that it might be possible.
>> 
>> Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean?
>
> Hmm, you're right, it's not totally clear. It's trying to draw the same sort of distinction that you have with mounted file systems, in which the mode that something is mounted in doesn't override any underlying read-only state.
> 
> For example you can still open a ZipFileSystem for a ZIP file which is on a remote drive, where the permissions show the underlying file as "writable", but an attempt to modify the contents would still fail.
> 
> The POSIX stuff is mentioned at the end, and while it's related, it's not quite the same point.

After thinking about it, I removed the sentence it only applied in edge cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091701964

From duke at openjdk.org  Thu May 15 17:54:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:54:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: 

On Wed, 14 May 2025 17:04:01 GMT, Lance Andersen  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 207:
> 
>> 205:                         Map.of("create", true, "accessMode", "badValue")));
>> 206:     }
>> 207: 
> 
> You could simplify the above tests using a DataProvider similar to
> 
> @DataProvider(name = "zipfsMap")
> protected Object[][] zipfsMap() {
>     return new Object[][]{
>             {Map.of(), NoSuchFileException.class},
>             {Map.of("accessMode", "readOnly"), NoSuchFileException.class},
>             {Map.of("accessMode", "readWrite"),  NoSuchFileException.class},
>             {Map.of("create", true, "accessMode", "readOnly"),  IllegalArgumentException.class},
>             {Map.of("create", true, "accessMode", "badValue"),  IllegalArgumentException.class},
>     };
> @Test(dataProvider = "zipfsMap?)
> public void testZipFSCreationException(Map env, Class exception) throws Exception {
>        assertThrows(exception, () -> FileSystems.newFileSystem(noSuchZip, env));
> }

Done. Thanks for giving the example, it really helped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091698261

From duke at openjdk.org  Thu May 15 18:27:35 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 18:27:35 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Changes based on review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/9b356a24..2326999b

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

  Stats: 66 lines in 3 files changed: 6 ins; 30 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

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

From naoto at openjdk.org  Thu May 15 18:32:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 18:32:53 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: 
References: 
Message-ID: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie  wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

test/jdk/sun/text/resources/LocaleDataTest.java line 106:

> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
> 106:  *        LocaleNames/fr_FR/US=?tats-Unis

This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2091757029

From alanb at openjdk.org  Fri May 16 05:36:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 May 2025 05:36:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/module-info.java line 299:

> 297:  *           
> 298:  *               Any other values will cause an {@code IllegalArgumentException}
> 299:  *               to be thrown.

The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2092352639

From michaelm at openjdk.org  Fri May 16 11:42:08 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 16 May 2025 11:42:08 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v10]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=09
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From jpai at openjdk.org  Fri May 16 14:25:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 14:25:59 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114:

> 112:     private final ZipPath rootdir;
> 113:     // Starts in readOnly (safe mode), but might be reset at the end of initialization.
> 114:     private boolean readOnly = true;

If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093154523

From jpai at openjdk.org  Fri May 16 14:32:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 14:32:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230:

> 228:         // It requires 'entryLookup' and 'readOnly' to have safe defaults (which
> 229:         // is why they are the only non-final fields), and it requires that the
> 230:         // inode map has been initialized.

It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults.

Perhaps something like:

> determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093167748

From jpai at openjdk.org  Fri May 16 14:39:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 14:39:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241:

> 239:         this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
> 240:         if (readOnly && accessMode == AccessMode.READ_WRITE) {
> 241:             String reason = Files.isWritable(zfpath)

Nit - this additional call to Files.isWritable(...) can be avoided if we store the value of the previous call (a couple of lines above). I realize that the previous `Files.isWritable` is stashed at the end of the `||` conditionals to prevent it from being invoked in certain situations.

So maybe a better change would be something like:


String reason = multiReleaseVersion.isPresent()
   ? "A multi-release JAR file opened with a specified version is not writable"
   : "The underlying ZIP file is not writable";


which would then avoid any additional calls to `Files.isWritable`.

But I think this point may not be relevant for the reason I note below as a separate comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093180117

From jpai at openjdk.org  Fri May 16 14:46:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 14:46:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 245:

> 243:                     : "The underlying ZIP file is not writable";
> 244:             throw new IOException(
> 245:                     "A writable ZIP file system could not be opened for: " + zfpath + "\n" + reason);

The JDK coding guidelines recommend excluding file paths from exception messages. So in this case the `zfpath` should be left out from the exception message. Additionally, I haven't seen us using newline characters in exception messages that we construct in the JDK code. So I think we should leave that out too. 

Given this, I think it might be simpler to just change this `if` block to something like:



if (...) {
    String reason = multiReleaseVersion.isPresent()
        ? "the multi-release JAR file is not writable"
        : "the ZIP file is not writable";

    throw new IOException(reason);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093192898

From lancea at openjdk.org  Fri May 16 15:44:55 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 May 2025 15:44:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 12 May 2025 09:49:12 GMT, David Beaumont  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221:
> 
>> 219:         }
>> 220:         // sm and existence check
>> 221:         zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ);
> 
> Type name clash with existing AccessMode class. Since new enum is private, happy to rename.

So perhaps change the name of the newly added enum

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259:
> 
>> 257: 
>> 258:         // Pass "this" as a parameter after everything else is set up.
>> 259:         this.rootdir = new ZipPath(this, new byte[]{'/'});
> 
> This could probably be set above release version etc. but it's a choice of either:
> 1. waiting until everything is set up before passing "this"
> 2. letting an incomplete "this" instance get passed to another class (possible escape risk?)
> 
> Though in this case the "incompleteness" is limited to it not being set up for multi-jar reading yet, which absolutely shouldn't affect the root path. It feels safer to me to leave it to the end, or perhaps we should dig in to ZipPath, figure out what it really wants here, and just call a different constructor?

I think it was fine where it was originally given how rootdir is used

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093248468
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093276490

From lancea at openjdk.org  Fri May 16 15:44:56 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 May 2025 15:44:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 16 May 2025 14:30:38 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230:
> 
>> 228:         // It requires 'entryLookup' and 'readOnly' to have safe defaults (which
>> 229:         // is why they are the only non-final fields), and it requires that the
>> 230:         // inode map has been initialized.
> 
> It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults.
> 
> Perhaps something like:
> 
>> determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed.

Not sure I see a need for the last sentence regarding the inode map having to be initialized in addition to Jai's comments above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093251313

From lancea at openjdk.org  Fri May 16 15:44:57 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 May 2025 15:44:57 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 16 May 2025 05:34:09 GMT, Alan Bateman  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/module-info.java line 299:
> 
>> 297:  *           

>> 298:  *               Any other values will cause an {@code IllegalArgumentException}
>> 299:  *               to be thrown.
> 
> The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too.

The IAE message would be best to standardize around the wording that the compressMethod property uses (same for releaseVersion while we are at it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093281557

From kbarrett at openjdk.org  Sun May 18 11:41:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 18 May 2025 11:41:59 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner
Message-ID: 

This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
use java.lang.ref.Cleaner.

This change is algorithmically similar to the two previous versions:
JDK-6857566 and JDK-8156500 (current mainline). The critical function is
Bits::reserveMemory(). For both of those versions and this change, a thread
calls that function and tries to reserve some space. If it fails, then it
keeps trying until all cleaners deactivated (cleared) by prior GCs have been
cleaned. If reservation still fails, then it invokes the GC to try to
deactivate more cleaners for cleaning. After that GC it keeps trying the
reservation and waiting for cleaning, with sleeps to avoid a spin loop,
eventually either succeeding or giving up and throwing OOME.

Retaining that algorithmic approach is one of the goals of this change, since
it has been successfully in use since JDK 9 (and was originally developed and
extensively tested in JDK 8).

The key to this approach is having a way to determine that deactivated
cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
threads help the reference processor until there was no available work.
JDK-8156500 waits for the reference processor to quiesce, relying on its
immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
to do this, which is why this change rolls its own Cleaner-like mechanism from
the underlying primitives. Like JDK-6857566, this change has waiting threads
help with cleaning references. This was a potentially undesirable feature of
JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
(Though by the time of JDK-6857566 the cleaners were only used by DBB, and
became internal-only somewhere around that time as well.) That's not a concern
here, as the cleaners involved are only from DBB, and we know what they look
like.

As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
being done off the reference processing thread, as it may be expensive and
slow down enqueuing other pending references. JDK-6857566 only did some of
that, and JDK-8156500 lost that feature. This change moves all of the DBB
cleaning off of the reference processing thread. (So does PR 22165.)

Neither JDK-6857566 nor this change are completely precise. For both, a thread
may find there is no available work while other threads have work in progress.
Making this change more precise seems to cost complexity and performance.
JDK-8156500 is precise in this respect, so we're losing that. But this
imprecision wasn't known to cause problems for JDK-6857566, and there hasn't
been any evidence of problems with this change either.

During the development of JDK-6857566 it was noticed that parallel cleaning
didn't seem to have much (if any) performance benefit. That seems to be true
for this change as well.

PR 22165 uses java.lang.ref.Cleaner to manage cleaning. That class doesn't
provide a good way to detect progress toward or completion of cleaning of
deactivated cleaners from prior GCs. So PR 22165 uses a somewhat clumsy and
unreliable mechanism (the canaries) to try to do that. A proposal for such
functionality was discussed (in PR 22165) but deemed (probably rightly so) too
intrusive. An unpublished alternative was less intrusive, but still might
raise questions. The change being proposed here avoids changing or using that
class, and performs at least as well.

Another issue with PR 22165 is that if we are indeed out of memory and on our
way to OOME, each allocating thread may come up against the slow path lock in
Bits::reserveMemory, and in turn perform 9 full GCs and then OOME. That seems
kind of pathological. For JDK-6857566, JDK-8156500, and this change, an
allocating thread only performs 1 full GC before OOME.

One issue with this change is that it incorporates a near-copy of the
CleanableList class from java.lang.ref.Cleaner. Possible future work would
merge the two into a common utility. There's another potential client for
this: java.desktop/share/classes/sun/java2d/Disposer.java. I tried using a
hashtable for this change (as with Disposer), but the CleanableList performed
significantly better.

A well-known issue with all of these approaches is -XX:+DisableExplicitGC. If
used, then the GCs to request reference processing don't happen. That will
likely lead to OOME, though the sleeps might provide an opportunity for
automatic GCs to occur, maybe sometimes dodging OOME that way.

https://mail.openjdk.org/pipermail/core-libs-dev/2013-October/021547.html
Thread for discussion of development of JDK-6857566

Testing: mach5 tier1-6

Many runs of new tests micro/org/openjdk/bench/java/nio/DirectByteBuffer{GC,Churn}
(thanks for those @shipilev), and jdk/java/nio/Buffer/DirectByteBufferAlloc
for various versions of this change.

The test java/nio/Buffer/DirectByteBufferAlloc.java can be run explicitly as a
benchmark. But the arguments suggested in that file cause the measurements to
be dominated by full GC times, swamping any other differences. Increasing the
value of `XX:MaxDirectMemorySize` from 128m to 1024m provides a more useful
comparison.

Result of running that test with `-XX:MaxDirectMemorySize=1024m`, with other
options as suggested in the file, and comparing the periodic per thread
`ms/allocation` outputs, produces results like this:

|        | this change  | PR 22165 | baseline |
| ------ | ------------ | -------- | -------- |
| avg    | 0.76165      | 1.00368  | 1.02719  |
| stddev | 0.12396      | 0.18361  | 0.27210  |
| min    | 0.54         | 0.6      | 0.59     |
| max    | 1.54         | 2.13     | 2.39     |

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

Commit messages:
 - copyrights
 - remove java.nio use of jdk.internal.ref.Cleaner
 - add micros from Shipilev

Changes: https://git.openjdk.org/jdk/pull/25289/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344332
  Stats: 499 lines in 9 files changed: 450 ins; 22 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289

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

From alanb at openjdk.org  Sun May 18 12:13:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 18 May 2025 12:13:59 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner
In-Reply-To: 
References: 
Message-ID: 

On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett  wrote:

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26:

> 24:  */
> 25: 
> 26: package jdk.internal.nio;

The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2094505609

From kbarrett at openjdk.org  Sun May 18 20:55:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 18 May 2025 20:55:48 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
Message-ID: 

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

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

  move jdk.internal.nio.Cleaner to sun.nio

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25289/files
  - new: https://git.openjdk.org/jdk/pull/25289/files/3ebf665c..45d0b1ef

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

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

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

From kbarrett at openjdk.org  Sun May 18 20:55:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 18 May 2025 20:55:49 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner
In-Reply-To: 
References: 
Message-ID: 

On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett  wrote:

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

BTW, I'm fine with a suggestion to wait until JDK 26 before integrating this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25289#issuecomment-2889206138

From kbarrett at openjdk.org  Sun May 18 20:55:50 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 18 May 2025 20:55:50 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 18 May 2025 12:11:21 GMT, Alan Bateman  wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package jdk.internal.nio;
> 
> The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together.

Good point.  Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2094623283

From dfuchs at openjdk.org  Mon May 19 11:09:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 19 May 2025 11:09:00 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 16 May 2025 11:42:08 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 78:

> 76:      * controlled. Consider using a unique value for the
> 77:      * SecurityProperties.includedInExceptions(String value) mechanism
> 78:      * Current values defined are "socket", "jar", "userInfo"

If I am not mistaken the "socket" info is no longer here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2095457460

From duke at openjdk.org  Mon May 19 11:35:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:35:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 16 May 2025 15:38:33 GMT, Lance Andersen  wrote:

>> src/jdk.zipfs/share/classes/module-info.java line 299:
>> 
>>> 297:  *           

>>> 298:  *               Any other values will cause an {@code IllegalArgumentException}
>>> 299:  *               to be thrown.
>> 
>> The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too.
>
> The IAE message would be best to standardize around the wording that the compressMethod property uses (same for releaseVersion while we are at it.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095504122

From duke at openjdk.org  Mon May 19 11:35:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:35:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
Message-ID: 

On Wed, 14 May 2025 16:42:07 GMT, Lance Andersen  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> test/jdk/jdk/nio/zipfs/TestPosix.java line 434:
> 
>> 432:         createTestZipFile(ZIP_FILE, ENV_DEFAULT).close();
>> 433:         // check entries on zipfs with default options
>> 434:         try (FileSystem zip = FileSystems.newFileSystem(ZIP_FILE, ENV_DEFAULT)) {
> 
> This tests an empty Map and should still be a test as it is different from ENV_READ_ONLY

Revert and added new ReadOnly variants of those tests. Thanks for calling me out on this, it was a bit sloppy of me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095503763

From duke at openjdk.org  Mon May 19 11:45:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:45:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>

On Fri, 16 May 2025 14:23:38 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114:
> 
>> 112:     private final ZipPath rootdir;
>> 113:     // Starts in readOnly (safe mode), but might be reset at the end of initialization.
>> 114:     private boolean readOnly = true;
> 
> If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't?

""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?""

If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents.

While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since:

1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.).

2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup).

I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour.

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 245:
> 
>> 243:                     : "The underlying ZIP file is not writable";
>> 244:             throw new IOException(
>> 245:                     "A writable ZIP file system could not be opened for: " + zfpath + "\n" + reason);
> 
> The JDK coding guidelines recommend excluding file paths from exception messages. So in this case the `zfpath` should be left out from the exception message. Additionally, I haven't seen us using newline characters in exception messages that we construct in the JDK code. So I think we should leave that out too. 
> 
> Given this, I think it might be simpler to just change this `if` block to something like:
> 
> 
> 
> if (...) {
>     String reason = multiReleaseVersion.isPresent()
>         ? "the multi-release JAR file is not writable"
>         : "the ZIP file is not writable";
> 
>     throw new IOException(reason);
> }

Thanks for letting me know. Now I think about the "no filename" things is very sensible for core libraries.
Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095517691
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095520598

From duke at openjdk.org  Mon May 19 11:45:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:45:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 16 May 2025 15:19:26 GMT, Lance Andersen  wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230:
>> 
>>> 228:         // It requires 'entryLookup' and 'readOnly' to have safe defaults (which
>>> 229:         // is why they are the only non-final fields), and it requires that the
>>> 230:         // inode map has been initialized.
>> 
>> It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults.
>> 
>> Perhaps something like:
>> 
>>> determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed.
>
> Not sure I see a need for the last sentence regarding the inode map having to be initialized in addition to Jai's comments above

Fair enough, removed. I err on the side of over explaining things for future maintainers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095518822

From duke at openjdk.org  Mon May 19 11:48:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:48:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 16 May 2025 15:17:40 GMT, Lance Andersen  wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221:
>> 
>>> 219:         }
>>> 220:         // sm and existence check
>>> 221:         zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ);
>> 
>> Type name clash with existing AccessMode class. Since new enum is private, happy to rename.
>
> So perhaps change the name of the newly added enum

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095527265

From duke at openjdk.org  Mon May 19 11:52:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:52:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 16 May 2025 14:37:28 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241:
> 
>> 239:         this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
>> 240:         if (readOnly && accessMode == AccessMode.READ_WRITE) {
>> 241:             String reason = Files.isWritable(zfpath)
> 
> Nit - this additional call to Files.isWritable(...) can be avoided if we store the value of the previous call (a couple of lines above). I realize that the previous `Files.isWritable` is stashed at the end of the `||` conditionals to prevent it from being invoked in certain situations.
> 
> So maybe a better change would be something like:
> 
> 
> String reason = multiReleaseVersion.isPresent()
>    ? "A multi-release JAR file opened with a specified version is not writable"
>    : "The underlying ZIP file is not writable";
> 
> 
> which would then avoid any additional calls to `Files.isWritable`.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095532769

From duke at openjdk.org  Mon May 19 12:01:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 12:01:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 16 May 2025 15:35:18 GMT, Lance Andersen  wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259:
>> 
>>> 257: 
>>> 258:         // Pass "this" as a parameter after everything else is set up.
>>> 259:         this.rootdir = new ZipPath(this, new byte[]{'/'});
>> 
>> This could probably be set above release version etc. but it's a choice of either:
>> 1. waiting until everything is set up before passing "this"
>> 2. letting an incomplete "this" instance get passed to another class (possible escape risk?)
>> 
>> Though in this case the "incompleteness" is limited to it not being set up for multi-jar reading yet, which absolutely shouldn't affect the root path. It feels safer to me to leave it to the end, or perhaps we should dig in to ZipPath, figure out what it really wants here, and just call a different constructor?
>
> I think it was fine where it was originally given how rootdir is used

I'd rather at least have it over the last part where the non-final fields are modified (in that state it's an instance functionally identical to one opened on a non-MR JAR).

Looking through the ZipPath code, it seems to (currently) only need to read back the ZipCoder field (but I'm still nervous about restoring the "this" escape to its original location since the ZipPath code might change one day and rely on something not initialized).

I moved it so it's the last final field initialized, but I'll revert it completely if you want.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095549535

From duke at openjdk.org  Mon May 19 12:12:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 12:12:10 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v5]
In-Reply-To: 
References: 
Message-ID: <8zTn8lVzIJC3VY0ZfQIDrMMGSGenVKBnqnqUCoKXdTA=.11f09e50-e233-400b-80f1-c475f606d48a@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Changes based on review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/2326999b..a82e4019

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

  Stats: 65 lines in 4 files changed: 35 ins; 7 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

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

From duke at openjdk.org  Mon May 19 12:15:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 12:15:38 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Fixed test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/a82e4019..ea781c16

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

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

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

From jpai at openjdk.org  Mon May 19 12:26:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:26:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>
References: 
 
 
 <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>
Message-ID: <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com>

On Mon, 19 May 2025 11:41:16 GMT, David Beaumont  wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114:
>> 
>>> 112:     private final ZipPath rootdir;
>>> 113:     // Starts in readOnly (safe mode), but might be reset at the end of initialization.
>>> 114:     private boolean readOnly = true;
>> 
>> If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't?
>
> ""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?""
> 
> If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents.
> 
> While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since:
> 
> 1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.).
> 
> 2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup).
> 
> I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour.

Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did:

diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
index e2fddd96fe8..f54b5360ac5 100644
--- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
+++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
@@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem {
     private final Path zfpath;
     final ZipCoder zc;
     private final ZipPath rootdir;
-    // Starts in readOnly (safe mode), but might be reset at the end of initialization.
-    private boolean readOnly = true;
+    private final boolean readOnly;
 
     // default time stamp for pseudo entries
     private final long zfsDefaultTimeStamp = System.currentTimeMillis();
@@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) {
 
         // Determining a release version uses 'this' instance to read paths etc.
         Optional multiReleaseVersion = determineReleaseVersion(env);
-
-        // Set the version-based lookup function for multi-release JARs.
-        this.entryLookup =
-                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
-
         // We only allow read-write zip/jar files if they are not multi-release
         // JARs and the underlying file is writable.
         this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
@@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) {
                     : "the ZIP file is not writable";
             throw new IOException(reason);
         }
+        // Set the version-based lookup function for multi-release JARs.
+        this.entryLookup =
+                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
+
     }
 
     /**




With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change.

Making it `final` and having it not accessed until the ultimate value is set in the constructor would get us past any of the concerns we may have about the "initial" value of `readOnly`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095587777

From jpai at openjdk.org  Mon May 19 12:26:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:26:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com>
References: 
 
 
 <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>
 <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com>
Message-ID: 

On Mon, 19 May 2025 12:22:11 GMT, Jaikiran Pai  wrote:

>> ""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?""
>> 
>> If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents.
>> 
>> While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since:
>> 
>> 1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.).
>> 
>> 2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup).
>> 
>> I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour.
>
> Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did:
> 
> 
> diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
> index e2fddd96fe8..f54b5360ac5 100644
> --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
> +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
> @@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem {
>      private final Path zfpath;
>      final ZipCoder zc;
>      private final ZipPath rootdir;
> -    // Starts in readOnly (safe mode), but might be reset at the end of initialization.
> -    private boolean readOnly = true;
> +    private final boolean readOnly;
>  
>      // default time stamp for pseudo entries
>      private final long zfsDefaultTimeStamp = System.currentTimeMillis();
> @@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) {
>  
>          // Determining a release version uses 'this' instance to read paths etc.
>          Optional multiReleaseVersion = determineReleaseVersion(env);
> -
> -        // Set the version-based lookup function for multi-release JARs.
> -        this.entryLookup =
> -                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
> -
>          // We only allow read-write zip/jar files if they are not multi-release
>          // JARs and the underlying file is writable.
>          this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
> @@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) {
>                      : "the ZIP file is not writable";
>              throw new IOException(reason);
>          }
> +        // Set the version-based lookup function for multi-release JARs.
> +        this.entryLookup =
> +                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
> +
>      }
>  
>      /**
> 
> 
> 
> 
> With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change.
> 
> Making it `final` and having it not accessed until the ultimate value is set in the constructor would get us past any of t...

On second thought, may be this isn't enough. I see that I missed the fact that `determineReleaseVersion()` requires access to `this`. Please leave this in the current form that you have in your PR. I need a few more moments to consider if anything needs to be changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095591964

From jpai at openjdk.org  Mon May 19 12:35:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:35:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

src/jdk.zipfs/share/classes/module-info.java line 290:

> 288:  *               already exist, and is incompatible with {@code "create"=true}.
> 289:  *               Specifying both will cause an {@code IllegalArgumentException}
> 290:  *               to be thrown when the Zip filesystem is created

To be precise, perhaps this last sentence should be reworded to:

> Specifying {@code create} as {@code true} and {@code accessMode} as {@code readOnly} will cause an {@code IllegalArgumentException} to be thrown when the ZIP filesystem is created.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095608509

From jpai at openjdk.org  Mon May 19 12:44:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:44:07 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: 
References: 
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 
 
Message-ID: 

On Thu, 15 May 2025 17:27:42 GMT, David Beaumont  wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167:
>> 
>>> 165:                     return null;
>>> 166:                 }
>>> 167:                 case String label when READ_WRITE.label.equals(label) -> {
>> 
>> I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler:
>> 
>> 
>> case "readWrite" -> {
>>    return READ_WRITE;
>> }
>> case "readOnly" -> {
>>    return READ_ONLY;
>> }
>
> Or just an if :)
> 
> The reason for the new style was the "need" for the "String label when" qualifier, which I don't actually need because String.equals(xx) copes with being given non-strings fine. You can't use the syntax you suggested in the new switch since "value" isn't a String.

Thank you for updating this to a traditional and trivial `if/else`.

>> src/jdk.zipfs/share/classes/module-info.java line 277:
>> 
>>> 275:  *   
>>> 276:  *       A value defining the desired read/write access mode of the file system
>>> 277:  *       (either read-write or read-only).
>> 
>> This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system.
>> 
>> Perhaps we could reword this to something like:
>> 
>>>
>>> A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access.
>
> Yeah, I tried to distinguish the accessMode flags (for which there are 3 states, ro, rw, n/a) and the final state of the file system from fs.isReadOnly(). Hence using `...` for whenever the actually resulting state is mentioned. I guess it wasn't clear enough.

Thank you for updating this part, this is much more clearer now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095625151
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095622485

From jpai at openjdk.org  Mon May 19 12:44:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:44:08 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 210:

> 208:             }
> 209:         }
> 210:         // sm and existence check

Nit - this is pre-existing, but would be good to cleanup. The "sm" here refers to SecurityManager. In JDK mainline, the SecurityManager is no longer present. So it would be good to change this comment to just "existence check" and remove reference to "sm".

src/jdk.zipfs/share/classes/module-info.java line 304:

> 302:  *           
> 303:  *       
> 304:  *       The access mode has no effect on reported POSIX file permissions (in cases

For consistency, I think this should be:

> The {@code accessMode} has no ....

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095621216
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095616802

From jpai at openjdk.org  Mon May 19 12:50:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:50:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208:

> 206:         // Multi-release JARs, when opened with a specified version are inherently read-only.
> 207:         Path multiReleaseJar = createMultiReleaseJar();
> 208:         try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) {

I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095637058

From jpai at openjdk.org  Mon May 19 12:56:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:56:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 224:

> 222:         // Underlying file is read-only.
> 223:         Path readOnlyZip = Utils.createJarFile("read_only.zip", Map.of("file.txt", "Hello World"));
> 224:         readOnlyZip.toFile().setReadOnly();

`java.io.File.setReadOnly()` specifies:

> On some platforms it may be possible to start the
> Java virtual machine with special privileges that allow it to modify
> files that are marked read-only. Whether or not a read-only file or
> directory may be deleted depends upon the underlying system.

So I think we should run the subsequent asserts in this test after first checking if the file was set to read-only. If it isn't then we should skip the test. Something like:


final boolean marked  = readOnlyZip.toFile().setReadOnly();
Assumptions.assumeTrue(marked, "skipping test since " + readOnlyZip + " couldn't be marked read-only");
assertThrows(IOException.class,
                () -> FileSystems.newFileSystem(readOnlyZip, Map.of("accessMode", "readWrite")));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095650541

From jpai at openjdk.org  Mon May 19 13:03:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:03:00 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

On a general note, all of these updated files will require a copyright year update.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 239:

> 237:             assertTrue(fs.isReadOnly());
> 238:             if (!"First version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) {
> 239:                 fail("unexpected file content");

Nit, for this and the other new `fail` statements, it might be good to include the unexpected file content in the fail message. If at all the test fails for whatever reason, that additional detail usually help to quickly debug the failures. Or maybe just replace the `if` followed by a `fail` with an `assertEquals()` call.

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

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2890930980
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095657482

From jpai at openjdk.org  Mon May 19 13:09:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:09:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 12 May 2025 10:01:05 GMT, David Beaumont  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test.
>
> test/jdk/jdk/nio/zipfs/Utils.java line 52:
> 
>> 50:      */
>> 51:     static Path createJarFile(String name, String... entries) throws IOException {
>> 52:         Path jarFile = Paths.get(name);
> 
> Previous tests always had the test file called the same thing.
> Note that in jtreg tests, the file of the same name often already exists in the test directory.
> I tried adding a "ensure file doesn't already exist" check and it fails lots of tests.

It's interesting that we have several places in the test which use this `Utils.createJarFile()` and pass it a test specific JAR file name and yet this utility was ignoring the passed name hard coding the name to `basic.jar`. It appears to be an oversight and your fix here I believe is a good thing.

> I tried adding a "ensure file doesn't already exist" check and it fails lots of tests.

I think it's OK in its current form to allow the file to be overwritten. Plus, you have also updated the javadoc of this test utility method to explicitly state its current behaviour, which I think is enough to let the call sites know how this behaves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095672596

From jpai at openjdk.org  Mon May 19 13:09:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:09:57 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/Utils.java line 52:

> 50:      */
> 51:     static Path createJarFile(String name, String... entries) throws IOException {
> 52:         Path jarFile = Paths.get(name);

In recent times we have replaced `Paths.get(...)` call in the JDK code with `Path.of(...)`. We should do the same here and the other line in this utility class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095676145

From jpai at openjdk.org  Mon May 19 13:14:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:14:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/Utils.java line 48:

> 46:      *
> 47:      * @param name the file name of the jar file to create in the working directory.
> 48:      * @param entries a list of JAR entries to be populated with random bytes.

Nit - maybe reword this to:

> @param entries JAR file entry names, whose content will be populated with random bytes.

test/jdk/jdk/nio/zipfs/Utils.java line 78:

> 76:      *
> 77:      * @param name the file name of the jar file to create in the working directory.
> 78:      * @param entries a map of relative file name path strings to file content

Nit - I think we should replace this description with something like:

> @param entries a map of JAR file entry names to entry content

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095686442
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095684096

From jpai at openjdk.org  Mon May 19 13:25:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:25:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
Message-ID: <87vFNxeXLspOxvNyBLBbVyAnEMwLSTCokW0o1fItFRM=.27c91bbb-9269-4b12-a443-8070dd61048f@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/TestPosix.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2025, SAP SE. All rights reserved.

For non-Oracle copyright lines like these, we don't edit them and instead we introduce a newline for the Oracle copyright year. So we should revert the change to this line and introduce the following new line just after this current one:

* Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095707195

From duke at openjdk.org  Mon May 19 13:33:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 13:33:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>
References: 
 
 <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>
Message-ID: 

On Mon, 19 May 2025 12:39:22 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 210:
> 
>> 208:             }
>> 209:         }
>> 210:         // sm and existence check
> 
> Nit - this is pre-existing, but would be good to cleanup. The "sm" here refers to SecurityManager. In JDK mainline, the SecurityManager is no longer present. So it would be good to change this comment to just "existence check" and remove reference to "sm".

Done.

> src/jdk.zipfs/share/classes/module-info.java line 290:
> 
>> 288:  *               already exist, and is incompatible with {@code "create"=true}.
>> 289:  *               Specifying both will cause an {@code IllegalArgumentException}
>> 290:  *               to be thrown when the Zip filesystem is created
> 
> To be precise, perhaps this last sentence should be reworded to:
> 
>> Specifying {@code create} as {@code true} and {@code accessMode} as {@code readOnly} will cause an {@code IllegalArgumentException} to be thrown when the ZIP filesystem is created.

Done.

> src/jdk.zipfs/share/classes/module-info.java line 304:
> 
>> 302:  *           
>> 303:  *       
>> 304:  *       The access mode has no effect on reported POSIX file permissions (in cases
> 
> For consistency, I think this should be:
> 
>> The {@code accessMode} has no ....

Done.

> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208:
> 
>> 206:         // Multi-release JARs, when opened with a specified version are inherently read-only.
>> 207:         Path multiReleaseJar = createMultiReleaseJar();
>> 208:         try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) {
> 
> I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file.

It does throw if accessMode=readWrite and the result is not writable for any reason.


this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
if (readOnly && accessMode == ZipAccessMode.READ_WRITE) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095718428
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095714913
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095715684
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095723172

From jpai at openjdk.org  Mon May 19 13:43:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:43:04 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
 <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>
 
Message-ID: 

On Mon, 19 May 2025 13:31:04 GMT, David Beaumont  wrote:

>> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208:
>> 
>>> 206:         // Multi-release JARs, when opened with a specified version are inherently read-only.
>>> 207:         Path multiReleaseJar = createMultiReleaseJar();
>>> 208:         try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) {
>> 
>> I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file.
>
> It does throw if accessMode=readWrite and the result is not writable for any reason.
> 
> 
> this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
> if (readOnly && accessMode == ZipAccessMode.READ_WRITE) {

Actually looking at the current proposed implementation in ZipFileSystem where we have:



this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
if (readOnly && accessMode == ZipAccessMode.READ_WRITE) {
    String reason = multiReleaseVersion.isPresent()
            ? "the multi-release JAR file is not writable"
            : "the ZIP file is not writable";
    throw new IOException(reason);
}


I'm surprised this test currently passes. Shouldn't this line in the test lead to an `IOException`:

FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite")))


Did I misread something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095732163

From duke at openjdk.org  Mon May 19 13:43:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 13:43:07 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 May 2025 12:58:00 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 239:
> 
>> 237:             assertTrue(fs.isReadOnly());
>> 238:             if (!"First version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) {
>> 239:                 fail("unexpected file content");
> 
> Nit, for this and the other new `fail` statements, it might be good to include the unexpected file content in the fail message. If at all the test fails for whatever reason, that additional detail usually help to quickly debug the failures. Or maybe just replace the `if` followed by a `fail` with an `assertEquals()` call.

Urgh, my bad. That's the hangover from these tests being first implemented in the ZipFSTester class without access to sensible assert methods.

> test/jdk/jdk/nio/zipfs/TestPosix.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2025, SAP SE. All rights reserved.
> 
> For non-Oracle copyright lines like these, we don't edit them and instead we introduce a newline for the Oracle copyright year. So we should revert the change to this line and introduce the following new line just after this current one:
> 
> * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Thanks! Done.

> test/jdk/jdk/nio/zipfs/Utils.java line 48:
> 
>> 46:      *
>> 47:      * @param name the file name of the jar file to create in the working directory.
>> 48:      * @param entries a list of JAR entries to be populated with random bytes.
> 
> Nit - maybe reword this to:
> 
>> @param entries JAR file entry names, whose content will be populated with random bytes.

Done.

> test/jdk/jdk/nio/zipfs/Utils.java line 52:
> 
>> 50:      */
>> 51:     static Path createJarFile(String name, String... entries) throws IOException {
>> 52:         Path jarFile = Paths.get(name);
> 
> In recent times we have replaced `Paths.get(...)` call in the JDK code with `Path.of(...)`. We should do the same here and the other line in this utility class.

Good spot, thanks.
Sadly I'm currently working on other code in which Path.of() is not permitted, so I won't naturally spot these things.

> test/jdk/jdk/nio/zipfs/Utils.java line 78:
> 
>> 76:      *
>> 77:      * @param name the file name of the jar file to create in the working directory.
>> 78:      * @param entries a map of relative file name path strings to file content
> 
> Nit - I think we should replace this description with something like:
> 
>> @param entries a map of JAR file entry names to entry content

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095730823
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095740846
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095740347
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095735890
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095738222

From duke at openjdk.org  Mon May 19 13:46:16 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 13:46:16 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Changes based on feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/ea781c16..46b19106

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

  Stats: 26 lines in 5 files changed: 6 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

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

From duke at openjdk.org  Mon May 19 14:04:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 14:04:08 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v8]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Changes based on feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/46b19106..3b3fe2d7

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

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

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

From jpai at openjdk.org  Mon May 19 14:04:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 14:04:08 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
 <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>
 
 
Message-ID: 

On Mon, 19 May 2025 13:35:37 GMT, Jaikiran Pai  wrote:

> Did I misread something?

I missed the fact that for a multi-release JAR file, we mark the file system as read-only, only if the `multi-release` or the `releaseVersion` environment properties have been set. So in this test here, the file system can indeed be opened in read-write mode. Sorry about the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095779244

From duke at openjdk.org  Mon May 19 14:04:09 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 14:04:09 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 May 2025 12:54:37 GMT, Jaikiran Pai  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 224:
> 
>> 222:         // Underlying file is read-only.
>> 223:         Path readOnlyZip = Utils.createJarFile("read_only.zip", Map.of("file.txt", "Hello World"));
>> 224:         readOnlyZip.toFile().setReadOnly();
> 
> `java.io.File.setReadOnly()` specifies:
> 
>> On some platforms it may be possible to start the
>> Java virtual machine with special privileges that allow it to modify
>> files that are marked read-only. Whether or not a read-only file or
>> directory may be deleted depends upon the underlying system.
> 
> So I think we should run the subsequent asserts in this test after first checking if the file was set to read-only. If it isn't then we should skip the test. Something like:
> 
> 
> final boolean marked  = readOnlyZip.toFile().setReadOnly();
> Assumptions.assumeTrue(marked, "skipping test since " + readOnlyZip + " couldn't be marked read-only");
> assertThrows(IOException.class,
>                 () -> FileSystems.newFileSystem(readOnlyZip, Map.of("accessMode", "readWrite")));

Done. Thanks for introducing me to the Assumptions class :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095780258

From duke at openjdk.org  Mon May 19 15:18:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 15:18:12 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v9]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Don't use JUnit utils in TestNg.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/3b3fe2d7..e5725599

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

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

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

From alanb at openjdk.org  Mon May 19 16:42:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 May 2025 16:42:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 May 2025 15:18:12 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't use JUnit utils in TestNg.

src/jdk.zipfs/share/classes/module-info.java line 264:

> 262:  *               {@linkplain Runtime.Version Java SE Platform version number},
> 263:  *               an {@code IllegalArgumentException} will be thrown when the Zip
> 264:  *               filesystem is created.

I think this needs to "when creating the ZIP file system".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096125703

From alanb at openjdk.org  Mon May 19 16:49:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 May 2025 16:49:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 May 2025 15:18:12 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't use JUnit utils in TestNg.

src/jdk.zipfs/share/classes/module-info.java line 288:

> 286:  *               isReadOnly()} will always return {@code true}. Creating a
> 287:  *               read-only file system requires the underlying ZIP file to
> 288:  *               already exist, and is incompatible with {@code "create"=true}.

I think it would be clearer to drop "and is incompatible with {@code "create"=true}". The sentence that follows makes it clear that accessMode=readWrite && create=true cause IAE to be thrown.

src/jdk.zipfs/share/classes/module-info.java line 291:

> 289:  *               Specifying {@code create} as {@code true} and {@code accessMode} as
> 290:  *               {@code readOnly} will cause an {@code IllegalArgumentException}
> 291:  *               to be thrown when the ZIP filesystem is created.

"created" sounds past tense, so making it "when creating the ZIP file system" would work better here. Same comment on the text further down.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096133967
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096134802

From duke at openjdk.org  Mon May 19 18:46:10 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 19 May 2025 18:46:10 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 18 May 2025 20:55:48 GMT, Kim Barrett  wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move jdk.internal.nio.Cleaner to sun.nio

src/java.base/share/classes/java/nio/Bits.java line 145:

> 143:                         // Increment with overflow to 0, so the value can
> 144:                         // never equal the initial/reset cleanedEpoch value.
> 145:                         RESERVE_GC_EPOCH = Integer.max(0, RESERVE_GC_EPOCH + 1);

Could?also do?the?following which?avoids the?branch in?`Integer.max`:
Suggestion:

                        RESERVE_GC_EPOCH = (RESERVE_GC_EPOCH + 1) & Integer.MAX_VALUE;

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

> 207:         super(-1, 0, cap, cap, fd, isSync, segment);
> 208:         address = addr;
> 209: 	cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);

**OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]:
Suggestion:

        cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);


[^1]:	- https://github.com/prettier/prettier/issues/7475
	- https://alexandersandberg.com/tabs-for-accessibility/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096283888
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096296130

From duke at openjdk.org  Mon May 19 18:49:52 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 19 May 2025 18:49:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 18 May 2025 20:50:41 GMT, Kim Barrett  wrote:

>> src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26:
>> 
>>> 24:  */
>>> 25: 
>>> 26: package jdk.internal.nio;
>> 
>> The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together.
>
> Good point.  Done.

But?`MhUtil` was?added to?the?newly created?`jdk.internal.invoke` package in? instead of?adding?it to?the?pre?existing `sun.invoke`?package.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096304667

From rriggs at openjdk.org  Mon May 19 19:37:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 19:37:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 18 May 2025 20:55:48 GMT, Kim Barrett  wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move jdk.internal.nio.Cleaner to sun.nio

The initial PR description is copied into every email. The detail in the PR is appreciated but can be less intrusive if included in a comment after the initial description.

src/java.base/share/classes/java/nio/Bits.java line 170:

> 168:             // without it that test likely fails.  Since failure here
> 169:             // ends in OOME, there's no need to hurry.
> 170:             for (int sleeps = 0; true; ) {

More typical coding pattern in openjdk code.  Here and elsewhere in this PR.
Suggestion:

            while (true) {
                int sleeps = 0;

src/java.base/share/classes/java/nio/BufferCleaner.java line 33:

> 31: import java.util.Objects;
> 32: import sun.nio.Cleaner;
> 33: 

A class cleaner describing the overall objective (an excerpt from the PR description) would be useful.

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

> 86:                 // Long-standing behavior: when deallocation fails, VM exits.
> 87:                 if (System.err != null) {
> 88:                     new Error("Cleaner terminated abnormally", x).printStackTrace();

The message would be more useful to identify this as a **Buffer** Cleaner terminated abnormally.

src/java.base/share/classes/sun/nio/Cleaner.java line 31:

> 29:  * {@code Cleaner} represents an object and a cleaning action.
> 30:  */
> 31: public interface Cleaner {

Can this be renamed NIOCleaner or NIOBufClenaer or something to avoid the ambiguity between the other cleaner.

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

PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2851749648
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096331929
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096341238
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096351666
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096355156

From rriggs at openjdk.org  Mon May 19 19:40:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 19:40:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 May 2025 18:40:56 GMT, ExE Boss  wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209:
> 
>> 207:         super(-1, 0, cap, cap, fd, isSync, segment);
>> 208:         address = addr;
>> 209: 	cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);
> 
> **OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]:
> Suggestion:
> 
>         cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);
> 
> 
> [^1]:	- prettier/prettier#7475
> 	- https://alexandersandberg.com/tabs-for-accessibility/

OpenJDK has not considered adoption of tabs-for-accessibility and sticks to using spaces across the codebase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096367503

From kbarrett at openjdk.org  Mon May 19 20:18:54 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 20:18:54 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <_Sn16clurXPHgVjZVt8Uq4uH4WeJ23qa1XTQnw3WY4w=.62794a53-a9d0-4eb6-a8df-62b04604b555@github.com>

On Mon, 19 May 2025 18:30:45 GMT, ExE Boss  wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Bits.java line 145:
> 
>> 143:                         // Increment with overflow to 0, so the value can
>> 144:                         // never equal the initial/reset cleanedEpoch value.
>> 145:                         RESERVE_GC_EPOCH = Integer.max(0, RESERVE_GC_EPOCH + 1);
> 
> Could?also do?the?following which?avoids the?branch in?`Integer.max`:
> Suggestion:
> 
>                         RESERVE_GC_EPOCH = (RESERVE_GC_EPOCH + 1) & Integer.MAX_VALUE;

I think the use of `Integer.max` is clearer, any performance difference is insignificant, and the compiler can
make that change as an optimization if appropriate. So I'm not inclined to accept this suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096422654

From kbarrett at openjdk.org  Mon May 19 20:22:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 20:22:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <3DkRh7Fg6uianW9tEAegtTMlS0XPR-p2-AVcG0AaM5c=.b7207af6-1340-4041-888f-ed76da0e321c@github.com>

On Mon, 19 May 2025 19:37:58 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209:
>> 
>>> 207:         super(-1, 0, cap, cap, fd, isSync, segment);
>>> 208:         address = addr;
>>> 209: 	cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);
>> 
>> **OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]:
>> Suggestion:
>> 
>>         cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);
>> 
>> 
>> [^1]:	- prettier/prettier#7475
>> 	- https://alexandersandberg.com/tabs-for-accessibility/
>
> OpenJDK has not considered adoption of tabs-for-accessibility and sticks to using spaces across the codebase.

I didn't notice that a tab had snuck in there.  Thanks for spotting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096427690

From kbarrett at openjdk.org  Mon May 19 20:36:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 20:36:51 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 May 2025 19:27:27 GMT, Roger Riggs  wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/sun/nio/Cleaner.java line 31:
> 
>> 29:  * {@code Cleaner} represents an object and a cleaning action.
>> 30:  */
>> 31: public interface Cleaner {
> 
> Can this be renamed NIOCleaner or NIOBufClenaer or something to avoid the ambiguity between the other cleaner.

I intentionally (re)used the "Cleaner" name to avoid a bunch of renames that
would increase the size of the change and distract from the meat of it. I
think the name to use might be affected by how the implementation of the set
of cleanup objects might get merged between the new java.nio.BufferCleaner and
java.lang.ref.Cleaner. Perhaps the java.lang.ref.Cleaner.Cleanable interface
should be used throughout? I didn't want to expand this change to include
those kinds of questions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096448999

From kbarrett at openjdk.org  Mon May 19 20:46:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 20:46:55 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 May 2025 19:24:57 GMT, Roger Riggs  wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 88:
> 
>> 86:                 // Long-standing behavior: when deallocation fails, VM exits.
>> 87:                 if (System.err != null) {
>> 88:                     new Error("Cleaner terminated abnormally", x).printStackTrace();
> 
> The message would be more useful to identify this as a **Buffer** Cleaner terminated abnormally.

This code was cribbed from https://github.com/openjdk/jdk/pull/22165, but your suggestion has led me to
discover that wasn't right. I'm going to need to do some rework of the exception handling around cleaning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096460505

From bpb at openjdk.org  Mon May 19 22:07:00 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 19 May 2025 22:07:00 GMT
Subject: RFR: 8357280: (bf) java/nio/Buffer/LimitDirectMemoryNegativeTest.java
 is not run on aarch64
Message-ID: 

Add missing `(os.arch == "aarch64")` to the `@requires` tag of the test.

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

Commit messages:
 - 8357280: (bf) java/nio/Buffer/LimitDirectMemoryNegativeTest.java is not run on aarch64

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

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

From alanb at openjdk.org  Tue May 20 06:26:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 06:26:51 GMT
Subject: RFR: 8357280: (bf)
 java/nio/Buffer/LimitDirectMemoryNegativeTest.java is not run on aarch64
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 May 2025 22:01:42 GMT, Brian Burkhalter  wrote:

> Add missing `(os.arch == "aarch64")` to the `@requires` tag of the test.

test/jdk/java/nio/Buffer/LimitDirectMemoryNegativeTest.java line 29:

> 27:  * @summary Test option to limit direct memory allocation,
> 28:  *          various bad values fail to launch the VM
> 29:  * @requires (os.arch == "x86_64") | (os.arch == "amd64") | (os.arch == "aarch64")

Is the `@requires` needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25311#discussion_r2097024394

From kbarrett at openjdk.org  Tue May 20 09:34:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 20 May 2025 09:34:51 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com>

On Mon, 19 May 2025 19:08:31 GMT, Roger Riggs  wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Bits.java line 170:
> 
>> 168:             // without it that test likely fails.  Since failure here
>> 169:             // ends in OOME, there's no need to hurry.
>> 170:             for (int sleeps = 0; true; ) {
> 
> More typical coding pattern in openjdk code.  Here and elsewhere in this PR.
> Suggestion:
> 
>             while (true) {
>                 int sleeps = 0;

That's not the same thing, and doesn't do what's needed here.  Perhaps you meant

int sleeps = 0;
while (true) {

I like limiting the scope of the variable.  Is that a suggestion or a request to change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2097487954

From pminborg at openjdk.org  Tue May 20 12:06:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 12:06:35 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address()
Message-ID: 

This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321

In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost.

This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

Commit messages:
 - Remove import
 - Remove comment
 - Use getBufferAddress() rather than address()

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

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

From pminborg at openjdk.org  Tue May 20 12:06:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 12:06:35 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address()
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 May 2025 10:51:13 GMT, Per Minborg  wrote:

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 254:

> 252:         ByteBuffer dst = Util.getTemporaryDirectBuffer(len);
> 253:         assert dst.position() == 0;
> 254:         NIO_ACCESS.acquireSession(dst);

Not strictly needed, but is proposed for consistency.

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:

> 457: 
> 458:             boolean pending = false;
> 459:             NIO_ACCESS.acquireSession(buf);

Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2097665536
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2097670174

From alanb at openjdk.org  Tue May 20 12:27:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 12:27:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address()
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 May 2025 10:51:13 GMT, Per Minborg  wrote:

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

We need to audit the tests for the APIs that take a byte buffer to ensure that we have tests to exercise these APIs with buffers that are views on a memory segment. That would help identify any bugs. 

The temporary buffer cache is internal so I think better to separate from this JBS issue and PR as these cases cannot be views on a memory segment. Future work to re-implement the temporary buffer cache can re-visit this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2894215287

From pminborg at openjdk.org  Tue May 20 12:49:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 12:49:06 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Revoke changes in classes that is always using DirectBuffer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/6e733a18..9c5a3573

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

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

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

From pminborg at openjdk.org  Tue May 20 12:54:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 12:54:06 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Clean up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/9c5a3573..f2764bf1

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

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

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

From alanb at openjdk.org  Tue May 20 13:40:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 13:40:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 12:54:06 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up

A question for folks onsecurity-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment?

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2894448506

From rriggs at openjdk.org  Tue May 20 14:42:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 May 2025 14:42:54 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com>
References: 
 
 
 <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com>
Message-ID: 

On Tue, 20 May 2025 09:32:08 GMT, Kim Barrett  wrote:

>> src/java.base/share/classes/java/nio/Bits.java line 170:
>> 
>>> 168:             // without it that test likely fails.  Since failure here
>>> 169:             // ends in OOME, there's no need to hurry.
>>> 170:             for (int sleeps = 0; true; ) {
>> 
>> More typical coding pattern in openjdk code.  Here and elsewhere in this PR.
>> Suggestion:
>> 
>>             while (true) {
>>                 int sleeps = 0;
>
> That's not the same thing, and doesn't do what's needed here.  Perhaps you meant
> 
> int sleeps = 0;
> while (true) {
> 
> I like limiting the scope of the variable.  Is that a suggestion or a request to change?

right, your form does better limit the scope of the loop, and is correct as is; (just looks unusual)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2098160773

From duke at openjdk.org  Tue May 20 15:05:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 20 May 2025 15:05:17 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v10]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Tweaking exact wording.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/e5725599..793e1856

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

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

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

From alanb at openjdk.org  Tue May 20 15:43:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 15:43:00 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 12:54:06 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up

src/java.base/share/classes/sun/nio/ch/Util.java line 46:

> 44: public class Util {
> 45: 
> 46:     static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess();

There are methods in IOUtil for the classes in sun.nio.ch. So no need to expose NIO_ACCESS here.

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 671:

> 669: 
> 670:             } finally {
> 671:                 NIO_ACCESS.releaseSession(buf);

I thin the change to WindowsAsynchronousFileChannel will need more than one reviewer as the I/O operation may complete on a different thread to the one that it was initiated on.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 764:

> 762:                     int outOfs = 0;
> 763:                     if (outBuffer instanceof DirectBuffer) {
> 764:                         outAddr = NIO_ACCESS.getBufferAddress(outBuffer);

This looks right.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1017:

> 1015:                 int outOfs = 0;
> 1016:                 if (outBuffer instanceof DirectBuffer) {
> 1017:                     outAddr = NIO_ACCESS.getBufferAddress(outBuffer);

This looks right.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Digest.java line 292:

> 290:             NIO_ACCESS.acquireSession(byteBuffer);
> 291:             try {
> 292:                 token.p11.C_DigestUpdate(session.id(), NIO_ACCESS.getBufferAddress(byteBuffer) + ofs, null, 0, len);

`long address = NIO_ACCESS.getBufferAddress(byteBuffer);` might be clearer here.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 289:

> 287:             NIO_ACCESS.acquireSession(byteBuffer);
> 288:             try  {
> 289:                 token.p11.C_SignUpdate(session.id(), NIO_ACCESS.getBufferAddress(byteBuffer) + ofs, null, 0, len);

I think I would introduce a long address here too, only to make the line easier to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098279301
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098297686
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098298906
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098299247
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098300469
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098302426

From bpb at openjdk.org  Tue May 20 15:48:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 May 2025 15:48:51 GMT
Subject: RFR: 8357280: (bf)
 java/nio/Buffer/LimitDirectMemoryNegativeTest.java is not run on aarch64
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 06:24:07 GMT, Alan Bateman  wrote:

>> Add missing `(os.arch == "aarch64")` to the `@requires` tag of the test.
>
> test/jdk/java/nio/Buffer/LimitDirectMemoryNegativeTest.java line 29:
> 
>> 27:  * @summary Test option to limit direct memory allocation,
>> 28:  *          various bad values fail to launch the VM
>> 29:  * @requires (os.arch == "x86_64") | (os.arch == "amd64") | (os.arch == "aarch64")
> 
> Is the `@requires` needed?

Perhaps not now that 32-bit is gone. Maybe this is a more general topic?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25311#discussion_r2098313526

From pminborg at openjdk.org  Tue May 20 15:52:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 15:52:06 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Add tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/f2764bf1..be261f56

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

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

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

From pminborg at openjdk.org  Tue May 20 16:10:07 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 16:10:07 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Update after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/be261f56..6435f777

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

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

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

From bpb at openjdk.org  Tue May 20 18:47:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 May 2025 18:47:07 GMT
Subject: RFR: 8357280: (bf) Remove @requires tag
 java/nio/Buffer/LimitDirectMemoryNegativeTest.java [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add missing `(os.arch == "aarch64")` to the `@requires` tag of the test.

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

  8357280: Remove @requires tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25311/files
  - new: https://git.openjdk.org/jdk/pull/25311/files/0b0e86b2..53c75e57

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

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

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

From bpb at openjdk.org  Tue May 20 18:47:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 May 2025 18:47:07 GMT
Subject: RFR: 8357280: (bf) Remove @requires tag
 java/nio/Buffer/LimitDirectMemoryNegativeTest.java [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 20 May 2025 15:45:48 GMT, Brian Burkhalter  wrote:

>> test/jdk/java/nio/Buffer/LimitDirectMemoryNegativeTest.java line 29:
>> 
>>> 27:  * @summary Test option to limit direct memory allocation,
>>> 28:  *          various bad values fail to launch the VM
>>> 29:  * @requires (os.arch == "x86_64") | (os.arch == "amd64") | (os.arch == "aarch64")
>> 
>> Is the `@requires` needed?
>
> Perhaps not now that 32-bit is gone. Maybe this is a more general topic?

The test passed on all platforms after the `@requires` tag was removed in 53c75e5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25311#discussion_r2098646226

From alanb at openjdk.org  Tue May 20 19:00:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 19:00:53 GMT
Subject: RFR: 8357280: (bf) Remove @requires tag
 java/nio/Buffer/LimitDirectMemoryNegativeTest.java [v2]
In-Reply-To: 
References: 
 
Message-ID: <--YBLsaeluvlgYLx7OfegsZ46oD-C9lP8ZGahxBud_o=.606ab343-19e6-401e-af78-18d72b67a1f6@github.com>

On Tue, 20 May 2025 18:47:07 GMT, Brian Burkhalter  wrote:

>> Add missing `(os.arch == "aarch64")` to the `@requires` tag of the test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357280: Remove @requires tag

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25311#pullrequestreview-2855283598

From swen at openjdk.org  Tue May 20 22:52:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 22:52:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 16:10:07 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 952:

> 950:                 // through a byte[] to get to the combined intrinsic
> 951:                 if (NIO_ACCESS.getBufferAddress(src) - srcaddr + src.position() >=
> 952:                         NIO_ACCESS.getBufferAddress(dst) - dstaddr + dst.position()) {

Suggestion:

                if (NIO_ACCESS.getBufferAddress(src) - srcaddr + src.position() >=
                    NIO_ACCESS.getBufferAddress(dst) - dstaddr + dst.position()) {

Here you can use the same alignment style as before

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1607:

> 1605:                             Unsafe.getUnsafe().setMemory(
> 1606:                                     NIO_ACCESS.getBufferAddress(dst),
> 1607:                                 len + dst.position(), (byte) 0);

Suggestion:

                                NIO_ACCESS.getBufferAddress(dst),
                                len + dst.position(), (byte) 0);

Alignment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098987037
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098988459

From swen at openjdk.org  Tue May 20 23:02:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 23:02:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 16:10:07 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 583:

> 581:             }
> 582:             default -> throw new InternalError("Should not reach here");
> 583:         };

Suggestion:

        return switch (rand.nextInt(3)) {
            case 0  -> ByteBuffer.allocateDirect(buf.length)
                                 .put(buf)
                                 .flip();
            case 1  -> ByteBuffer.wrap(buf);
            case 2  -> Arena.ofAuto()
                            .allocate(buf.length)
                            .asByteBuffer()
                            .put(buf)
                            .flip();
            default -> throw new InternalError("Should not reach here");
        };

ByteBuffer supports chain programming style, so we can simplify it to this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098997233

From bpb at openjdk.org  Tue May 20 23:17:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 May 2025 23:17:37 GMT
Subject: RFR: 8357280: (bf) Remove @requires tags from
 java/nio/Buffer/LimitDirectMemory[NegativeTest].java [v3]
In-Reply-To: 
References: 
Message-ID: 

> Add missing `(os.arch == "aarch64")` to the `@requires` tag of the test.

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

  8357280: Remove @requires from LimitDirectMemory also

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25311/files
  - new: https://git.openjdk.org/jdk/pull/25311/files/53c75e57..c41e9a89

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

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

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

From bpb at openjdk.org  Tue May 20 23:21:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 May 2025 23:21:51 GMT
Subject: RFR: 8357280: (bf) Remove @requires tags from
 java/nio/Buffer/LimitDirectMemory[NegativeTest].java [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 23:17:37 GMT, Brian Burkhalter  wrote:

>> Remove the `@requires` tag from the affected tests.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357280: Remove @requires from LimitDirectMemory also

The `@requires` tag has also been removed from `LimitDirectMemory` as of c41e9a8. Both tests pass on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/25311#issuecomment-2896042980

From valeriep at openjdk.org  Wed May 21 01:05:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 21 May 2025 01:05:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: 
References: 
 
Message-ID: <1EFXzrYvM3fhV_mggScPO3sVnRRfSipz75__819ckZ0=.0c186ff7-e80a-49be-89fd-fe54753ec5a7@github.com>

On Tue, 20 May 2025 16:10:07 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/share/classes/sun/nio/ch/Util.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved.

I didn't see src changes in this class? Maybe you meant to update the copyright year for `IOUtil.java`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2099102725

From valeriep at openjdk.org  Wed May 21 01:08:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 21 May 2025 01:08:55 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 16:10:07 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 176:

> 174:                 dst.position(pos + n);
> 175:                 return n;
> 176:             }  finally {

nit: extra space before finally?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2099108417

From kbarrett at openjdk.org  Wed May 21 02:36:16 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 May 2025 02:36:16 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v3]
In-Reply-To: 
References: 
Message-ID: 

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:

 - add description of BufferCleaner class
 - exception handling in cleaner for backward consistency
 - detabify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25289/files
  - new: https://git.openjdk.org/jdk/pull/25289/files/45d0b1ef..be3312cb

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

  Stats: 40 lines in 2 files changed: 28 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289

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

From kbarrett at openjdk.org  Wed May 21 02:36:17 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 May 2025 02:36:17 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 May 2025 19:16:14 GMT, Roger Riggs  wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/BufferCleaner.java line 33:
> 
>> 31: import java.util.Objects;
>> 32: import sun.nio.Cleaner;
>> 33: 
> 
> A class cleaner describing the overall objective (an excerpt from the PR description) would be useful.

Assume you meant "class comment".  I've added such.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2099181042

From valeriep at openjdk.org  Wed May 21 05:02:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 21 May 2025 05:02:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 20 May 2025 13:38:11 GMT, Alan Bateman  wrote:

> A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment?

I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2896582775

From kbarrett at openjdk.org  Wed May 21 05:44:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 May 2025 05:44:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 May 2025 02:36:16 GMT, Kim Barrett  wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - add description of BufferCleaner class
>  - exception handling in cleaner for backward consistency
>  - detabify

src/java.base/share/classes/java/nio/BufferCleaner.java line 82:

> 80:                         new Error("nio Cleaner terminated abnormally", x).printStackTrace();
> 81:                     }
> 82:                     System.exit(1);

This is the same behavior as jdk.internal.ref.Cleaner, for which this class is
substituting in the new regime for DBB management. PR 22165 (and earlier
versions of this PR) put this in the DBB's Deallocator::run method, but I
think it's both clearer here, and better to leave the Deallocator as it was in
mainline and be more consistent with the mainline code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2099400318

From alanb at openjdk.org  Wed May 21 06:14:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 06:14:51 GMT
Subject: RFR: 8357280: (bf) Remove @requires tags from
 java/nio/Buffer/LimitDirectMemory[NegativeTest].java [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 23:17:37 GMT, Brian Burkhalter  wrote:

>> Remove the `@requires` tag from the affected tests.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357280: Remove @requires from LimitDirectMemory also

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25311#pullrequestreview-2856415976

From alanb at openjdk.org  Wed May 21 07:54:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 07:54:05 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 15:05:17 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaking exact wording.

src/jdk.zipfs/share/classes/module-info.java line 264:

> 262:  *               {@linkplain Runtime.Version Java SE Platform version number},
> 263:  *               an {@code IllegalArgumentException} will be thrown when the Zip
> 264:  *               filesystem is created.

Minor comment, I think you want "when creating the ZIP file system" here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2099609806

From alanb at openjdk.org  Wed May 21 09:14:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 09:14:00 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 21 May 2025 05:00:16 GMT, Valerie Peng  wrote:

> > A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment?
> 
> I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed.

Thanks for checking. We need to create an issue in JBS for this. It may be a corner case to use these APIs and SPI with buffers that are views on a memory segment but it will happen at some point and would be good to ensure that it is covered by tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2897203363

From duke at openjdk.org  Wed May 21 10:43:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 21 May 2025 10:43:12 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v11]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Tweaking exact wording.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/793e1856..ab15123a

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

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

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

From pminborg at openjdk.org  Wed May 21 13:31:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 May 2025 13:31:53 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 21 May 2025 09:10:57 GMT, Alan Bateman  wrote:

> > > A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment?
> > 
> > 
> > I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed.
> 
> Thanks for checking. We need to create an issue in JBS for this. It may be a corner case to use these APIs and SPI with buffers that are views on a memory segment but it will happen at some point and would be good to ensure that it is covered by tests.

I've created https://bugs.openjdk.org/browse/JDK-8357466. There are some missing fields, I hope someone can fill them in.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2897977877

From pminborg at openjdk.org  Wed May 21 13:38:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 May 2025 13:38:12 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Update after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/6435f777..538147be

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

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

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

From pminborg at openjdk.org  Wed May 21 13:42:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 May 2025 13:42:39 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/538147be..d6b4233e

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

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

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

From bpb at openjdk.org  Wed May 21 15:25:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 May 2025 15:25:05 GMT
Subject: Integrated: 8357280: (bf) Remove @requires tags from
 java/nio/Buffer/LimitDirectMemory[NegativeTest].java
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 May 2025 22:01:42 GMT, Brian Burkhalter  wrote:

> Remove the `@requires` tag from the affected tests.

This pull request has now been integrated.

Changeset: 275cfd32
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/275cfd323b1b7b5e8927e7be2f229d200bac9980
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8357280: (bf) Remove @requires tags from java/nio/Buffer/LimitDirectMemory[NegativeTest].java

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Wed May 21 15:36:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 May 2025 15:36:03 GMT
Subject: RFR: 8357303: (fs) UnixSecureDirectoryStream.implDelete has unused
 haveFlags parameter
Message-ID: 

Remove the `haveFlags` parameter of `UnixSecureDirectoryStream.implDelete` and all code which would execute if `haveFlags` were `false`.

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

Commit messages:
 - 8357303: (fs) UnixSecureDirectoryStream.implDelete has unused haveFlags parameter

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

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

From bpb at openjdk.org  Wed May 21 15:36:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 May 2025 15:36:03 GMT
Subject: RFR: 8357303: (fs) UnixSecureDirectoryStream.implDelete has unused
 haveFlags parameter
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 May 2025 15:30:41 GMT, Brian Burkhalter  wrote:

> Remove the `haveFlags` parameter of `UnixSecureDirectoryStream.implDelete` and all code which would execute if `haveFlags` were `false`.

Examination of historical versions of `UnixSecureDirectoryStream.java` shows that `haveFlags` was always `true`. The proposed change passes `jdk_nio` tests in the CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/25359#issuecomment-2898391357

From alanb at openjdk.org  Wed May 21 16:16:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 16:16:53 GMT
Subject: RFR: 8357303: (fs) UnixSecureDirectoryStream.implDelete has unused
 haveFlags parameter
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 May 2025 15:30:41 GMT, Brian Burkhalter  wrote:

> Remove the `haveFlags` parameter of `UnixSecureDirectoryStream.implDelete` and all code which would execute if `haveFlags` were `false`.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25359#pullrequestreview-2858391266

From valeriep at openjdk.org  Wed May 21 17:57:53 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 21 May 2025 17:57:53 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 May 2025 11:01:46 GMT, Per Minborg  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year
>
> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:
> 
>> 457: 
>> 458:             boolean pending = false;
>> 459:             NIO_ACCESS.acquireSession(buf);
> 
> Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown.

Is there documentation on when sessions should be acquired/released? Is this only for when using MemorySegment? In security area, the bytes are passed to the JNI code which calls the native library to process the bytes and I wonder if sessions should be acquired/released for these.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2100870190

From vyazici at openjdk.org  Wed May 21 21:02:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 21:02:04 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
Message-ID: 

There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.

### Fixing strategy

* Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
* Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
* Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.

@naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.

### Scanning strategy

The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:


# Perl is used for multi-line matching
find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
git grep -H 'FileDescriptor.in' "*.java"


All calls to `InputStreamReader::new` and `Scanner::new` are checked too.

### Problems encountered

1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:

    ```
    DOMImplementationRegistry 
    InputRC 
    ListingErrorHandler 
    PandocFilter 
    ```
2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

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

Commit messages:
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356893
  Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368

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

From rriggs at openjdk.org  Wed May 21 21:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:39:53 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici  wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

There too many changes in too many different areas to be in a single PR.
Please break it down by review areas.  Client, core libs, tools, etc.

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

PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030

From lancea at openjdk.org  Wed May 21 22:20:59 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 May 2025 22:20:59 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 May 2025 10:43:12 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaking exact wording.

src/jdk.zipfs/share/classes/module-info.java line 279:

> 277:  *       
> 278:  *           
> 279:  *               If no value is set, the file system is created read-write

created -> created as

I think it might be better as 

> If no value is specified, the file system is created as ....

src/jdk.zipfs/share/classes/module-info.java line 289:

> 287:  *               read-only file system requires the underlying ZIP file to
> 288:  *               already exist.
> 289:  *               Specifying {@code create} as {@code true} and {@code accessMode} as

> Specifying {@code  create} 

You should make this clear that it is the 'create property '

src/jdk.zipfs/share/classes/module-info.java line 291:

> 289:  *               Specifying {@code create} as {@code true} and {@code accessMode} as
> 290:  *               {@code readOnly} will cause an {@code IllegalArgumentException}
> 291:  *               to be thrown when creating the ZIP file system.

I 'think' this should be "cause a" or "result in a" for the usages  of "cause an" based on how the phrase is used

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101259671
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101262569
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101257012

From duke at openjdk.org  Wed May 21 23:30:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 21 May 2025 23:30:18 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: 
References: 
Message-ID: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  More tweaking...

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/ab15123a..92355287

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

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

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

From bpb at openjdk.org  Thu May 22 00:18:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 May 2025 00:18:10 GMT
Subject: RFR: 8356888: (fs) FileSystems.newFileSystem that take an env must
 specify IllegalArgumentException
Message-ID: 

Add a throws clause for `IllegalArgumentException` to the `java.nio.file.FileSystems` methods `newFileSystem(Path, Map)` and `newFileSystem(Path, Map, ClassLoader)`. Also update the equivalent IAE verbiage for the analogous methods which accept a `URI` parameter instead of a `Path`.

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

Commit messages:
 - 8356888: (fs) FileSystems.newFileSystem that take an env must specify IllegalArgumentException

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

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

From alanb at openjdk.org  Thu May 22 05:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 05:54:52 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici  wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

javax.swing.text.DefaultEditorKit.read(InputStream ...)  is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`.  From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753

From vyazici at openjdk.org  Thu May 22 07:59:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:09 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs  wrote:

>> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
>> 
>> ### Fixing strategy
>> 
>> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
>> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
>> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
>> 
>> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
>> 
>> ### Scanning strategy
>> 
>> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
>> 
>> 
>> # Perl is used for multi-line matching
>> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
>> git grep -H 'FileDescriptor.in' "*.java"
>> 
>> 
>> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
>> 
>> ### Problems encountered
>> 
>> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
>> 
>>     ```
>>     DOMImplementationRegistry 
>>     InputRC 
>>     ListingErrorHandler 
>>     PandocFilter 
>>     ```
>> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property
>
> There too many changes in too many different areas to be in a single PR.
> Please break it down by review areas.  Client, core libs, tools, etc.

@RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will

1. withdraw this PR,
2. convert certain changes to spec clarifications,
3. and break it down to multiple PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422

From vyazici at openjdk.org  Thu May 22 07:59:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:10 GMT
Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici  wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

This pull request has been closed without being integrated.

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

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

From shade at openjdk.org  Thu May 22 08:25:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 08:25:51 GMT
Subject: RFR: 8357303: (fs) UnixSecureDirectoryStream.implDelete has unused
 haveFlags parameter
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 May 2025 15:30:41 GMT, Brian Burkhalter  wrote:

> Remove the `haveFlags` parameter of `UnixSecureDirectoryStream.implDelete` and all code which would execute if `haveFlags` were `false`.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25359#pullrequestreview-2860265915

From alanb at openjdk.org  Thu May 22 11:26:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 11:26:51 GMT
Subject: RFR: 8356888: (fs) FileSystems.newFileSystem that take an env must
 specify IllegalArgumentException
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 May 2025 00:13:57 GMT, Brian Burkhalter  wrote:

> Add a throws clause for `IllegalArgumentException` to the `java.nio.file.FileSystems` methods `newFileSystem(Path, Map)` and `newFileSystem(Path, Map, ClassLoader)`. Also update the equivalent IAE verbiage for the analogous methods which accept a `URI` parameter instead of a `Path`.

The update wording in the existing descriptions looks okay, and adding it to the JDK 13+ methods is good, an oversight that the exception descriptions were missed.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25376#pullrequestreview-2860855355

From jpai at openjdk.org  Thu May 22 12:18:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 12:18:52 GMT
Subject: RFR: 8356888: (fs) FileSystems.newFileSystem that take an env must
 specify IllegalArgumentException
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 May 2025 00:13:57 GMT, Brian Burkhalter  wrote:

> Add a throws clause for `IllegalArgumentException` to the `java.nio.file.FileSystems` methods `newFileSystem(Path, Map)` and `newFileSystem(Path, Map, ClassLoader)`. Also update the equivalent IAE verbiage for the analogous methods which accept a `URI` parameter instead of a `Path`.

The change looks OK to me. While at it, should we add a regression test to verify that IllegalArgumentException gets thrown for some the filesystem implementations that we ship in the JDK?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25376#pullrequestreview-2860997111

From lancea at openjdk.org  Thu May 22 12:44:53 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 May 2025 12:44:53 GMT
Subject: RFR: 8356888: (fs) FileSystems.newFileSystem that take an env must
 specify IllegalArgumentException
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 May 2025 00:13:57 GMT, Brian Burkhalter  wrote:

> Add a throws clause for `IllegalArgumentException` to the `java.nio.file.FileSystems` methods `newFileSystem(Path, Map)` and `newFileSystem(Path, Map, ClassLoader)`. Also update the equivalent IAE verbiage for the analogous methods which accept a `URI` parameter instead of a `Path`.

Hi Brian,

Thanks for adding the IAE to the javadoc for these methods which I missed when I added these.

overall looks good

One minor missing update is that we should add `@since 13` to
`public static FileSystem newFileSystem(Path path, ClassLoader loader)`

Which I added as part of the additions of these methods

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

Changes requested by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25376#pullrequestreview-2861075801

From alanb at openjdk.org  Thu May 22 12:44:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 12:44:53 GMT
Subject: RFR: 8356888: (fs) FileSystems.newFileSystem that take an env must
 specify IllegalArgumentException
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 22 May 2025 12:16:23 GMT, Jaikiran Pai  wrote:

> The change looks OK to me. While at it, should we add a regression test to verify that IllegalArgumentException gets thrown for some the filesystem implementations that we ship in the JDK?

Not for this PR but it would be useful to check the zipfs tests (there are some, but maybe not not all IAE are tested).

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

PR Comment: https://git.openjdk.org/jdk/pull/25376#issuecomment-2901086899

From bpb at openjdk.org  Thu May 22 15:20:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 May 2025 15:20:07 GMT
Subject: Integrated: 8357303: (fs) UnixSecureDirectoryStream.implDelete has
 unused haveFlags parameter
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 May 2025 15:30:41 GMT, Brian Burkhalter  wrote:

> Remove the `haveFlags` parameter of `UnixSecureDirectoryStream.implDelete` and all code which would execute if `haveFlags` were `false`.

This pull request has now been integrated.

Changeset: 72e440d0
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/72e440d06e6a93141e8943f1a62610cd951e22c4
Stats:     18 lines in 1 file changed: 0 ins; 14 del; 4 mod

8357303: (fs) UnixSecureDirectoryStream.implDelete has unused haveFlags parameter

Reviewed-by: alanb, shade

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

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

From bpb at openjdk.org  Thu May 22 15:33:36 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 May 2025 15:33:36 GMT
Subject: RFR: 8356888: (fs) FileSystems.newFileSystem that take an env must
 specify IllegalArgumentException [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add a throws clause for `IllegalArgumentException` to the `java.nio.file.FileSystems` methods `newFileSystem(Path, Map)` and `newFileSystem(Path, Map, ClassLoader)`. Also update the equivalent IAE verbiage for the analogous methods which accept a `URI` parameter instead of a `Path`.

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

  8356888: Added @since 13 to newFileSystem(Path,C;assLoader)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25376/files
  - new: https://git.openjdk.org/jdk/pull/25376/files/03e3df16..982ef6d6

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

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

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

From bpb at openjdk.org  Thu May 22 15:33:36 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 May 2025 15:33:36 GMT
Subject: RFR: 8356888: (fs) FileSystems.newFileSystem that take an env must
 specify IllegalArgumentException [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 22 May 2025 12:41:45 GMT, Lance Andersen  wrote:

> [...] add `@since 13` to `public static FileSystem newFileSystem(Path
> path, ClassLoader loader)` [...]

Added in [982ef6d](https://github.com/openjdk/jdk/pull/25376/commits/982ef6d646bd7b02d1e837953c1f4f473d4c8012).

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

PR Comment: https://git.openjdk.org/jdk/pull/25376#issuecomment-2901675070

From lancea at openjdk.org  Thu May 22 15:38:52 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 May 2025 15:38:52 GMT
Subject: RFR: 8356888: (fs) FileSystems.newFileSystem that take an env must
 specify IllegalArgumentException [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 22 May 2025 15:33:36 GMT, Brian Burkhalter  wrote:

>> Add a throws clause for `IllegalArgumentException` to the `java.nio.file.FileSystems` methods `newFileSystem(Path, Map)` and `newFileSystem(Path, Map, ClassLoader)`. Also update the equivalent IAE verbiage for the analogous methods which accept a `URI` parameter instead of a `Path`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356888: Added @since 13 to newFileSystem(Path,C;assLoader)

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25376#pullrequestreview-2861711997

From valeriep at openjdk.org  Thu May 22 18:57:51 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 22 May 2025 18:57:51 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 May 2025 13:42:39 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

Security source changes look fine.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2862279408

From valeriep at openjdk.org  Thu May 22 18:57:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 22 May 2025 18:57:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 21 May 2025 17:55:17 GMT, Valerie Peng  wrote:

>> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:
>> 
>>> 457: 
>>> 458:             boolean pending = false;
>>> 459:             NIO_ACCESS.acquireSession(buf);
>> 
>> Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown.
>
> Is there documentation on when sessions should be acquired/released? Is this only for when using MemorySegment? In security area, the bytes are passed to the JNI code which calls the native library to process the bytes and I wonder if sessions should be acquired/released for these.

Never mind, I see that there are already acquireSession/releaseSession calls when the ByteBuffer objects are accessed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2103213937

From prr at openjdk.org  Thu May 22 21:45:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:45:52 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie  wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:

> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
> 48:  * 
> 49:  * MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);

This is javadoc inJava SE specification. As is the Action case below.
I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:

> 61: 
> 62:     private static final String INSTRUCTIONS =
> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "

I really don't like these tests being changed. It isn't part of the JDK build.
People compile these in all sorts of locales.
Please revert all the changes in the client tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103439338
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103431874

From shade at openjdk.org  Fri May 23 09:10:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 May 2025 09:10:13 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: 
References: 
 
Message-ID: <4qOq3AQt4RJI9yPvjXJSva2ZMyhqSOLqH3ERDX8csBg=.0ddce86f-eaba-41fd-9677-10e2090edaf1@github.com>

On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev  wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit more comments

Closing in favor of https://git.openjdk.org/jdk/pull/25289.

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2903787453

From jpai at openjdk.org  Fri May 23 13:57:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 May 2025 13:57:57 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
References: 
 <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
Message-ID: 

On Wed, 21 May 2025 23:30:18 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More tweaking...

This looks good to me. I would have prefered not changing the intial value of a the `readOnly` field to `true`, because that would mean one less thing to be concerned about. However, I am not too sure if it makes a practical difference. So what you have I think is OK. I'll think about it a bit more later and if anything shows up, I think we can address it. 

I think this enhancement deserves a release note, so I have added that label to the JBS issue. Instructions for creating a release note are available here https://openjdk.org/guide/#release-notes.

Thank you David for being patient with the back and forth discussions and reviews. Please wait for Alan and Lance to have a chance to look at the final state of this PR before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2864523197

From lancea at openjdk.org  Fri May 23 15:14:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 23 May 2025 15:14:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
References: 
 <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
Message-ID: 

On Wed, 21 May 2025 23:30:18 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More tweaking...

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1451:

> 1449:         }
> 1450:         int version;
> 1451:         if (o instanceof String) {

Any reason to not use:

> 
    if (o instanceof String s) {
        if (s.equals("runtime")) {
            version = Runtime.version().feature();
        } else else if (s.matches("^[1-9][0-9]*$")) { {
            version = Version.parse(s).feature();;
            }
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2104803699

From sherman at openjdk.org  Fri May 23 23:28:54 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 23 May 2025 23:28:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
References: 
 <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
Message-ID: 

On Wed, 21 May 2025 23:30:18 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More tweaking...

Looks like I'm late to the party :-) My apologies if this has already been discussed a long time ago. My question is whether it's really necessary to restrict the 'read-only' flag to existing ZIP files only. I don't see any issue with allowing the creation of a new, empty ZIP file and marking it as read-only. Sure, it might be useless since it's just an empty zip file system, but that's up to the user.  Not a very strong opinion though.

283  *           

284  *               If the value is {@code "readOnly"}, the file system is created
285  *               read-only, and {@link java.nio.file.FileSystem#isReadOnly()
286  *               isReadOnly()} will always return {@code true}. Creating a
287  *               read-only file system requires the underlying ZIP file to
288  *               already exist.
289  *               Specifying the {@code create} property as {@code true} with the
290  *               {@code accessMode} as {@code readOnly} will cause an {@code
291  *               IllegalArgumentException} to be thrown when creating the ZIP file
292  *               system.
293  *           

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

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2906012555

From alanb at openjdk.org  Sat May 24 06:31:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 May 2025 06:31:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: 
References: 
 <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
 
Message-ID: 

On Fri, 23 May 2025 23:25:59 GMT, Xueming Shen  wrote:

> Looks like I'm late to the party :-) My apologies if this has already been discussed a long time ago. My question is whether it's really necessary to restrict the 'read-only' flag to existing ZIP files only. I don't see any issue with allowing the creation of a new, empty ZIP file and marking it as read-only. Sure, it might be useless since it's just an empty zip file system, but that's up to the user. Not a very strong opinion though.

In the file system API, the "CREATE" option is specified to be ignored when opening a file for only reading. This means an I/O exception if the file doesn't exist. This was a pragmatic choice at the time that requires the full table of combinations and their outcome to see.

For zipfs, the doing the same, or rejecting having the env contain both create=true and accessMode=readOnly, is okay. We chatted with David about this recently and agreed that rejecting this combination makes the most sense. It means someone has opt'ed it for both options, which is different to the file system API where it defaults to "READ" if none of the read/write/append options are provided.

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

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2906503159

From alanb at openjdk.org  Mon May 26 07:35:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 07:35:18 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 May 2025 13:42:39 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 169:

> 167:         int rem = (pos <= lim ? lim - pos : 0);
> 168: 
> 169:         if (dst instanceof sun.nio.ch.DirectBuffer) {

I assume this can be changed to test dst.isDirect() now and avoid the explicit cross package dependency.

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 41:

> 39: import jdk.internal.invoke.MhUtil;
> 40: 
> 41: import static sun.nio.ch.Util.NIO_ACCESS;

I assume this is left over from a previous iteration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106733233
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106735489

From ihse at openjdk.org  Mon May 26 07:47:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 07:47:02 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
References: 
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
Message-ID: 

On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato  wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
> 
>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
> 
> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 

However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160

From alanb at openjdk.org  Mon May 26 08:16:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 08:16:09 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 May 2025 13:42:39 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:

> 457: 
> 458:             boolean pending = false;
> 459:             IOUtil.acquireScope(buf, true);

Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true.

test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 575:

> 573:             case 2 -> Arena.ofAuto().allocate(buf.length).asByteBuffer()
> 574:                     .put(buf)
> 575:                     .flip();

I wonder if we could extend this to test with a shared arena too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106767298
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106771546

From ihse at openjdk.org  Mon May 26 08:20:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:19 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: 
References: 
Message-ID: 

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/9c904992..7184e685

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

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

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

From ihse at openjdk.org  Mon May 26 08:20:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:46 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: 
References: 
 
Message-ID: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>

On Thu, 22 May 2025 21:43:20 GMT, Phil Race  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:
> 
>> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
>> 48:  * 
>> 49:  * MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);
> 
> This is javadoc inJava SE specification. As is the Action case below.
> I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

The resulting Javadoc html files will contain the same character before and after this fix, so there is no specification change. 

I did this since I thought it increased readability of the source code, but I can just as well revert it.

> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
> 
>> 61: 
>> 62:     private static final String INSTRUCTIONS =
>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
> 
> I really don't like these tests being changed. It isn't part of the JDK build.
> People compile these in all sorts of locales.
> Please revert all the changes in the client tests.

Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.

The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?

Let me know if you still want me to revert it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106769659
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106791184

From ihse at openjdk.org  Mon May 26 08:21:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:21:16 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: 
References: 
 
Message-ID: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>

On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie  wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:

> 88:                 printKey(e);
> 89:                 int keychar = e.getKeyChar();
> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b

@prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:

> 186:                     +          "\"After\" lists.\n"
> 187:                     + "              Added printers are highlighted with "
> 188:                     +               "green color, removed ones \u2014 with "

@prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.

Do you still want me to revert it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106774492
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106778974

From michaelm at openjdk.org  Mon May 26 10:31:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 May 2025 10:31:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=10
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From dfuchs at openjdk.org  Mon May 26 11:33:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 May 2025 11:33:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2868122303

From pminborg at openjdk.org  Mon May 26 12:50:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 May 2025 12:50:54 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 26 May 2025 07:51:32 GMT, Alan Bateman  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year
>
> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:
> 
>> 457: 
>> 458:             boolean pending = false;
>> 459:             IOUtil.acquireScope(buf, true);
> 
> Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true.

WASCI is using acquireScopes (plural) and this delegates to aquireScope(.., async=true). So, looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107273542

From pminborg at openjdk.org  Mon May 26 14:22:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 May 2025 14:22:10 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v8]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/d6b4233e..ec233e0c

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

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

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

From alanb at openjdk.org  Mon May 26 15:53:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 15:53:57 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 26 May 2025 12:47:55 GMT, Per Minborg  wrote:

>> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:
>> 
>>> 457: 
>>> 458:             boolean pending = false;
>>> 459:             IOUtil.acquireScope(buf, true);
>> 
>> Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true.
>
> WASCI is using acquireScopes (plural) and this delegates to aquireScope(.., async=true). So, looks good.

Good, thanks for checking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107592606

From alanb at openjdk.org  Mon May 26 16:07:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 16:07:54 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 May 2025 14:22:10 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 669:

> 667: 
> 668:             } finally {
> 669:                 IOUtil.releaseScope(buf);

I don't think we can release here when there is an I/O pending. I suspect it will need to go into releaseBufferIfSubstituted. 

TBH, I think the change to Windows implementation of AsynchronousFileChannel are going to take more eyes and significant testing. What would you think about dropping it from this PR and creating a separate JBS issue as this is going to require more cycles that everything else in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107608913

From msheppar at openjdk.org  Mon May 26 17:10:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:10:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

new file => copyright ?

Copyright (c) 2025,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107664521

From msheppar at openjdk.org  Mon May 26 17:31:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:31:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130:

> 128:         public abstract String output();
> 129: 
> 130:         protected String output(boolean enhance) {

to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot
suggest
refactor rename this method name to composeFilteredMessageText  or composeFilteredText or just compose

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107682303

From msheppar at openjdk.org  Mon May 26 17:42:59 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:42:59 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58:

> 56:  *     public static SensitiveInfo filterUserName(String name)
> 57:  */
> 58: public final class Exceptions {

maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107691017

From msheppar at openjdk.org  Mon May 26 18:15:56 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 18:15:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/java/net/HostPortrange.java line 73:

> 71: 
> 72:         // first separate string into two fields: hoststr, portstr
> 73:         String hoststr = null, portstr = null;

you could take the opportunity to update the HostPortrange constructor signature refactor rename
the parameter str to hostname  ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107715671

From msheppar at openjdk.org  Mon May 26 19:09:53 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 19:09:53 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
Message-ID: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:

> 251:             return;
> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")

This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.

Consider the following: 
includeInException specifies the type of information that maybe included in an enhanced exception 
e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
This defines an information policy 

developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply

an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107759746

From alanb at openjdk.org  Mon May 26 19:25:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 19:25:00 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
References: 
 
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
Message-ID: 

On Mon, 26 May 2025 19:06:56 GMT, Mark Sheppard  wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
> 
>> 251:             return;
>> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
>> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")
> 
> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket.
> 
> Consider the following: 
> includeInException specifies the type of information that maybe included in an enhanced exception 
> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
> This defines an information policy 
> 
> developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply
> 
> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages

> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.

I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo".  It does mean repurposing the name but it's a good name going forward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107784068

From msheppar at openjdk.org  Mon May 26 20:42:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 20:42:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt
a builder pattern for the creation of the filter exceptions, for example 

 FilteredExceptionBuilder / EnhancedExceptionBuilder.

It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder.

EnhancedExceptionBuilder::class()
::exceptionMessage()
::port()
::hostname()
::userDetails()
::filterPolicy()

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2910598238

From msheppar at openjdk.org  Mon May 26 21:46:52 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 21:46:52 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
 
Message-ID: 

On Mon, 26 May 2025 19:22:39 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
>> 
>>> 251:             return;
>>> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
>>> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")
>> 
>> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket.
>> 
>> Consider the following: 
>> includeInException specifies the type of information that maybe included in an enhanced exception 
>> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
>> This defines an information policy 
>> 
>> developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply
>> 
>> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages
>
>> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.
> 
> I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo".  It does mean repurposing the name but it's a good name going forward.

The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used. 
But equally the setting hostInfoExclSocket suggests some knowledge of APIs is available, so there is a contradiction in the rationale presented above
Also the setting enhancedNonSocketExceptionText is inclusive of the setting enhancedSocketExceptionText, which adds further subtleties to the configuration, which was previously suggested should be avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107873149

From alanb at openjdk.org  Tue May 27 06:12:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 06:12:53 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
 
 
Message-ID: 

On Mon, 26 May 2025 21:44:32 GMT, Mark Sheppard  wrote:

> The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used.

Right, what is now "hostInfoExclSocket" is a confusing category and not easy to explain to anyone. However it is the long standing default. If you relax the default then security people will complain. If you make it more strict then developers will complain as it makes troubleshooting harder. With the current proposal then nobody has to deal with this confusing named category. Instead, if you want reveal more exceptions then you run with the property set to hostInfo, a category that is much simpler to understand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2108262111

From duke at openjdk.org  Tue May 27 09:28:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 27 May 2025 09:28:19 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v13]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont 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 13 additional commits since the last revision:

 - Merge updates from master
 - More tweaking...
 - Tweaking exact wording.
 - Tweaking exact wording.
 - Don't use JUnit utils in TestNg.
 - Changes based on feedback
 - Changes based on feedback
 - Fixed test.
 - Changes based on review feedback.
 - Changes based on review feedback.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9c8b2f42...593c3a9b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/92355287..593c3a9b

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

  Stats: 112295 lines in 2398 files changed: 65646 ins; 32848 del; 13801 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

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

From pminborg at openjdk.org  Tue May 27 11:23:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 11:23:55 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 26 May 2025 16:05:13 GMT, Alan Bateman  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 669:
> 
>> 667: 
>> 668:             } finally {
>> 669:                 IOUtil.releaseScope(buf);
> 
> I don't think we can release here when there is an I/O pending. I suspect it will need to go into releaseBufferIfSubstituted. 
> 
> TBH, I think the change to Windows implementation of AsynchronousFileChannel are going to take more eyes and significant testing. What would you think about dropping it from this PR and creating a separate JBS issue as this is going to require more cycles that everything else in this PR.

Sounds like a good idea: https://bugs.openjdk.org/browse/JDK-8357847

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2108922601

From pminborg at openjdk.org  Tue May 27 11:28:42 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 11:28:42 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v9]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Revert copyright year
 - Revoke changes in WAFCI

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/ec233e0c..c2a901b3

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

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

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

From duke at openjdk.org  Tue May 27 11:30:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 27 May 2025 11:30:40 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v14]
In-Reply-To: 
References: 
Message-ID: <3SOzBKrNslFY6xVPq1TgAeX5eSiaPpy1Jo_VXjEqcE8=.2de6ca06-97ce-43cd-a4a1-3b2a39c95192@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Tweak wording again...

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/593c3a9b..3e93e53f

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

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

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

From pminborg at openjdk.org  Tue May 27 11:50:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 11:50:14 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v10]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

Per Minborg 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 13 additional commits since the last revision:

 - Merge branch 'master' into jdk-segment-access
 - Revert copyright year
 - Revoke changes in WAFCI
 - Address comments
 - Fix copyright year
 - Update after comments
 - Update after comments
 - Add tests
 - Clean up
 - Revoke changes in classes that is always using DirectBuffer
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ede001e6...1eb284df

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/c2a901b3..1eb284df

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

  Stats: 57006 lines in 826 files changed: 38176 ins; 13844 del; 4986 mod
  Patch: https://git.openjdk.org/jdk/pull/25324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324

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

From alanb at openjdk.org  Tue May 27 12:46:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 12:46:57 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 27 May 2025 11:50:14 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg 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 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-segment-access
>  - Revert copyright year
>  - Revoke changes in WAFCI
>  - Address comments
>  - Fix copyright year
>  - Update after comments
>  - Update after comments
>  - Add tests
>  - Clean up
>  - Revoke changes in classes that is always using DirectBuffer
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/5abc863c...1eb284df

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2870926691

From pminborg at openjdk.org  Tue May 27 12:49:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 12:49:56 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 27 May 2025 11:50:14 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg 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 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-segment-access
>  - Revert copyright year
>  - Revoke changes in WAFCI
>  - Address comments
>  - Fix copyright year
>  - Update after comments
>  - Update after comments
>  - Add tests
>  - Clean up
>  - Revoke changes in classes that is always using DirectBuffer
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/ca90399f...1eb284df

I am reverting to 1 reviewer, as we have removed the asynchronous Windows class.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2912390902

From pminborg at openjdk.org  Tue May 27 13:01:09 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 13:01:09 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v11]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Revert changes in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/1eb284df..dcb67a79

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

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

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

From alanb at openjdk.org  Tue May 27 13:09:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 13:09:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 27 May 2025 13:01:09 GMT, Per Minborg  wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes in test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2871010526

From dfuchs at openjdk.org  Tue May 27 13:36:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 May 2025 13:36:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: 
References: 
 
 
 <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>
 <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com>
 
Message-ID: 

On Mon, 19 May 2025 12:24:28 GMT, Jaikiran Pai  wrote:

>> Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did:
>> 
>> 
>> diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
>> index e2fddd96fe8..f54b5360ac5 100644
>> --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
>> +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
>> @@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem {
>>      private final Path zfpath;
>>      final ZipCoder zc;
>>      private final ZipPath rootdir;
>> -    // Starts in readOnly (safe mode), but might be reset at the end of initialization.
>> -    private boolean readOnly = true;
>> +    private final boolean readOnly;
>>  
>>      // default time stamp for pseudo entries
>>      private final long zfsDefaultTimeStamp = System.currentTimeMillis();
>> @@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) {
>>  
>>          // Determining a release version uses 'this' instance to read paths etc.
>>          Optional multiReleaseVersion = determineReleaseVersion(env);
>> -
>> -        // Set the version-based lookup function for multi-release JARs.
>> -        this.entryLookup =
>> -                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
>> -
>>          // We only allow read-write zip/jar files if they are not multi-release
>>          // JARs and the underlying file is writable.
>>          this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
>> @@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) {
>>                      : "the ZIP file is not writable";
>>              throw new IOException(reason);
>>          }
>> +        // Set the version-based lookup function for multi-release JARs.
>> +        this.entryLookup =
>> +                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
>> +
>>      }
>>  
>>      /**
>> 
>> 
>> 
>> 
>> With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change.
>> 
>> Making it `final` and having...
>
> On second thought, may be this isn't enough. I see that I missed the fact that `determineReleaseVersion()` requires access to `this`. Please leave this in the current form that you have in your PR. I need a few more moments to consider if anything needs to be changed.

final members are good! Alternatively if making it final is not an option you could consider replacing:

private boolean readOnly;

with

private boolean readWrite;

I  looked at where `readOnly` was used and there are not that many places, so inverting the flag might not be too intrusive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2109210071

From naoto at openjdk.org  Tue May 27 16:37:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:37:56 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: 
References: 
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
 
Message-ID: 

On Mon, 26 May 2025 07:44:30 GMT, Magnus Ihse Bursie  wrote:

>> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
>> 
>>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
>> 
>> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.
>
> ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 
> 
> However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

Thanks. Filed an issue to change the encoding in the test to UTF-8: https://bugs.openjdk.org/browse/JDK-8357882

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2109668481

From bpb at openjdk.org  Tue May 27 17:14:00 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 May 2025 17:14:00 GMT
Subject: Integrated: 8356888: (fs) FileSystems.newFileSystem that take an env
 must specify IllegalArgumentException
In-Reply-To: 
References: 
Message-ID: <90eLDTDll2bWTOpvu7xybrzGF-gzTHV0SQK8QH2z-9w=.4d33abc9-b273-424b-8925-912e5ccd97c2@github.com>

On Thu, 22 May 2025 00:13:57 GMT, Brian Burkhalter  wrote:

> Add a throws clause for `IllegalArgumentException` to the `java.nio.file.FileSystems` methods `newFileSystem(Path, Map)` and `newFileSystem(Path, Map, ClassLoader)`. Also update the equivalent IAE verbiage for the analogous methods which accept a `URI` parameter instead of a `Path`.

This pull request has now been integrated.

Changeset: c1f066e1
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/c1f066e17eacf7649df4042e2fb985da9724ef40
Stats:     17 lines in 1 file changed: 12 ins; 0 del; 5 mod

8356888: (fs) FileSystems.newFileSystem that take an env must specify IllegalArgumentException

Reviewed-by: lancea, alanb, jpai

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

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

From pminborg at openjdk.org  Tue May 27 19:14:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 19:14:05 GMT
Subject: Integrated: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address()
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 May 2025 10:51:13 GMT, Per Minborg  wrote:

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

This pull request has now been integrated.

Changeset: d4b923d1
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/d4b923d175b07e39ee8ee2c79f04457ea1cfbdd0
Stats:     78 lines in 14 files changed: 17 ins; 0 del; 61 mod

8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address()

Reviewed-by: alanb, valeriep

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

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

From duke at openjdk.org  Tue May 27 19:21:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 27 May 2025 19:21:45 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v15]
In-Reply-To: 
References: 
Message-ID: 

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

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

  Simplifying parsing of version parameter.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/3e93e53f..fb8dd750

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=13-14

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

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

From alanb at openjdk.org  Tue May 27 19:53:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 19:53:29 GMT
Subject: Integrated: 8357912: (fs) Remove @since tag from
 java.nio.file.FileSystems.newFileSystem(Path,ClassLoader)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 27 May 2025 19:44:33 GMT, Brian Burkhalter  wrote:

> Remove invalid `@since` tag.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25472#pullrequestreview-2872398260

From bpb at openjdk.org  Tue May 27 19:53:29 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 May 2025 19:53:29 GMT
Subject: Integrated: 8357912: (fs) Remove @since tag from
 java.nio.file.FileSystems.newFileSystem(Path,ClassLoader)
Message-ID: 

Remove invalid `@since` tag.

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

Commit messages:
 - 8357912: (fs) Remove @since tag from java.nio.file.FileSystems.newFileSystem(Path,ClassLoader)

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

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

From bpb at openjdk.org  Tue May 27 19:53:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 May 2025 19:53:30 GMT
Subject: Integrated: 8357912: (fs) Remove @since tag from
 java.nio.file.FileSystems.newFileSystem(Path,ClassLoader)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 27 May 2025 19:44:33 GMT, Brian Burkhalter  wrote:

> Remove invalid `@since` tag.

This pull request has now been integrated.

Changeset: 4755276f
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/4755276f36ccc989d9171fc9f92f8e886d4d99b9
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8357912: (fs) Remove @since tag from java.nio.file.FileSystems.newFileSystem(Path,ClassLoader)

Reviewed-by: lancea, alanb

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

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

From lancea at openjdk.org  Tue May 27 19:53:29 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 May 2025 19:53:29 GMT
Subject: Integrated: 8357912: (fs) Remove @since tag from
 java.nio.file.FileSystems.newFileSystem(Path,ClassLoader)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 27 May 2025 19:44:33 GMT, Brian Burkhalter  wrote:

> Remove invalid `@since` tag.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25472#pullrequestreview-2872394284

From bpb at openjdk.org  Tue May 27 19:53:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 May 2025 19:53:30 GMT
Subject: Integrated: 8357912: (fs) Remove @since tag from
 java.nio.file.FileSystems.newFileSystem(Path,ClassLoader)
In-Reply-To: 
References: 
Message-ID: <1zO_P3Ppuk-UM4yYcJpd5Pn-wgwzMn_L_8mwLsu1KKs=.bc045545-0538-482f-b19d-e6f212d12c96@github.com>

On Tue, 27 May 2025 19:44:33 GMT, Brian Burkhalter  wrote:

> Remove invalid `@since` tag.

The method in question was in place since JDK 1.7.

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

PR Comment: https://git.openjdk.org/jdk/pull/25472#issuecomment-2913813593

From alexei.olkhovskii at servicenow.com  Tue May 27 22:50:36 2025
From: alexei.olkhovskii at servicenow.com (Alexei Olkhovskii)
Date: Tue, 27 May 2025 22:50:36 +0000
Subject: NIO Socket.read() may not respect the socket timeout
Message-ID: 

Hello,

We?ve ran into a corner-case issue with socket read(). In short, it doesn?t honor socket timeout when trying to acquire the read lock:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L336

  readLock.lock();

In our case one thread obtained a database connection and got stuck in read() (we think because of a StackOverflow). The thread was holding the readLock. Our connection pool gave the connection to another thread which tried to clean it up. While doing that, it attempted to drain the socket with 3 millisecond timeout:

  socket.setSoTimeout(3);        // supposed to prevent blocking
  InputStream is = socket.getInputStream();
  while (is.read() != -1) {      // blocked forever because of the JDK lock
         //read byte
  }

We think that instead of unconditional locking the method should use its timed version like accept() is doing:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L715

Note: the fix may also be applied to connect().

The test case is attached.

--
Regards, Alexei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SocketTimeoutNotRespected.java
Type: application/octet-stream
Size: 3823 bytes
Desc: SocketTimeoutNotRespected.java
URL: 

From alan.bateman at oracle.com  Wed May 28 05:59:37 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 28 May 2025 06:59:37 +0100
Subject: NIO Socket.read() may not respect the socket timeout
In-Reply-To: 
References: 
Message-ID: 



On 27/05/2025 23:50, Alexei Olkhovskii wrote:
>
> Hello,
>
> We?ve ran into a corner-case issue with socket read(). In short, it 
> doesn?t honor socket timeout when trying to acquire the read lock:
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L336
>
> readLock.lock();
>
> In our case one thread obtained a database connection and got stuck in 
> read() (we think because of a StackOverflow).
>

Would it be possible to do some digging to say for sure if this happens 
after StackOverflowError (SOE)? There have been a few reports of issues 
that appear to be lock "corruption" when continuing after SOE and it may 
be that the reserved stack area for critical sections needs to be 
re-visited.

As regards the test. Can you confirm you created this to demonstrate 
your point and isn't representative of what the code is doing? For a 
TCP/stream connection then having several threads reading from the same 
connection would require coordination at a high level. If it does arise 
that one thread is blocked reading and another thread attempts to read 
from the same connection then it is blocked until the first thread 
finishes reading. It would be a strange scenario to arise and different 
to the accept case where it's okay to have concurrently threads attempt 
to accept connections, they don't interfere.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From michaelm at openjdk.org  Wed May 28 11:13:12 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:13:12 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - ... and 20 more: https://git.openjdk.org/jdk/compare/0671309d...cf179f7d

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=11
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From michaelm at openjdk.org  Wed May 28 11:34:58 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:34:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 26 May 2025 17:07:45 GMT, Mark Sheppard  wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> new file => copyright ?
> 
> Copyright (c) 2025,

The file isn't actually new, though webrev doesn't seem to realise that on this occasion (sometimes it does recognise name changes). It was previously named SocketExceptions. I presume we keep the existing header in that case?

> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130:
> 
>> 128:         public abstract String output();
>> 129: 
>> 130:         protected String output(boolean enhance) {
> 
> to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot
> suggest
> refactor rename this method name to composeFilteredMessageText  or composeFilteredText or just compose

Okay, I'll use one of those options, whichever fits best space wise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111618040
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111620553

From michaelm at openjdk.org  Wed May 28 11:38:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:38:01 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 26 May 2025 17:40:39 GMT, Mark Sheppard  wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58:
> 
>> 56:  *     public static SensitiveInfo filterUserName(String name)
>> 57:  */
>> 58: public final class Exceptions {
> 
> maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter

I see what you mean, but the class does more than just filter messages. It also generates new Exception objects from existing ones. Given that its original name was `SocketExceptions` and all we've done here is generalize it to work with other exception types, I think `Exceptions` is a reasonable name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111626402

From duke at openjdk.org  Wed May 28 12:19:34 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Wed, 28 May 2025 12:19:34 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can result
 in large TTSP spikes
Message-ID: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>

ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.

This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its that straightforward as mentionedby Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
 
I can pursue that if that is preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.

I added a benchmark for potential perf regression, following are the results.

**Before**

Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
ByteBufferAllocationBenchmark.allocateDirectBuffer         128  avgt   25        860.869 ?     170.921  ns/op
ByteBufferAllocationBenchmark.allocateDirectBuffer        1024  avgt   25       1368.599 ?     320.159  ns/op
ByteBufferAllocationBenchmark.allocateDirectBuffer     1048576  avgt   25      80169.230 ?     448.075  ns/op
ByteBufferAllocationBenchmark.allocateDirectBuffer  2147483647  avgt   25  635047372.458 ? 5461328.161  ns/op

**After**

Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
ByteBufferAllocationBenchmark.allocateDirectBuffer         128  avgt   25        869.676 ?     160.633  ns/op
ByteBufferAllocationBenchmark.allocateDirectBuffer        1024  avgt   25       1328.623 ?     282.198  ns/op
ByteBufferAllocationBenchmark.allocateDirectBuffer     1048576  avgt   25      80224.157 ?     454.906  ns/op
ByteBufferAllocationBenchmark.allocateDirectBuffer  2147483647  avgt   25  667037308.198 ? 4818648.535  ns/op

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

Commit messages:
 - change output timeunit to nanoseconds
 - add benchmark for allocation
 - zero out memory in chunk size of 1MB

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

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

From shade at openjdk.org  Wed May 28 12:19:34 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 May 2025 12:19:34 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: 

On Wed, 28 May 2025 09:30:56 GMT, Rohitash Kumar  wrote:

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its that straightforward as mentionedby Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if that is preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> I added a benchmark for potential perf regression, following are the results.
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         128  avgt   25        860.869 ?     170.921  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer        1024  avgt   25       1368.599 ?     320.159  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer     1048576  avgt   25      80169.230 ?     448.075  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer  2147483647  avgt   25  635047372.458 ? 5461328.161  ns/op
> 
> **After**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         128  avgt   25        869.676 ?     160.633  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer        1024  avgt   25       1328.623 ?     282.198  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer     1048576  avgt   25      80224.157 ?     454.906  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer  2147483647  avgt   25  667037308.198 ? 4818648.535  ns/op

Filed [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959) -- please rename the PR to "8357959: Long TTSP spikes for large Unsafe.setMemory initializations" to hook it up.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2915803930

From duke at openjdk.org  Wed May 28 12:46:38 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Wed, 28 May 2025 12:46:38 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v2]
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: <9daRPddZDVKrMkF0OhiJbtPaDhNp3GHWB4wHM3fa9qY=.6724f53f-2abd-43a8-8a17-ac3c187081bb@github.com>

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> I added a benchmark for potential perf regression, following are the results.
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         128  avgt   25        860.869 ?     170.921  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer        1024  avgt   25       1368.599 ?     320.159  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer     1048576  avgt   25      80169.230 ?     448.075  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer  2147483647  avgt   25  635047372.458 ? 5461328.161  ns/op
> 
> **After**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         128  avgt   25        869.676 ?     160.633  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer        1024  avgt   25       1328.623 ?     282.198  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer     1048576  avgt   25      80224.157 ?     454.906  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer  2147483647  avgt   25  667037308.198 ? 4818648.535  ns/op

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

  update license and stylistic improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/3aa67da1..03567436

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

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

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

From kbarrett at openjdk.org  Wed May 28 13:19:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 May 2025 13:19:45 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v4]
In-Reply-To: 
References: 
Message-ID: 

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

Kim Barrett 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 nine additional commits since the last revision:

 - Merge branch 'master' into direct-buffer-cleaner
 - Merge branch 'master' into direct-buffer-cleaner
 - add description of BufferCleaner class
 - exception handling in cleaner for backward consistency
 - detabify
 - move jdk.internal.nio.Cleaner to sun.nio
 - copyrights
 - remove java.nio use of jdk.internal.ref.Cleaner
 - add micros from Shipilev

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25289/files
  - new: https://git.openjdk.org/jdk/pull/25289/files/be3312cb..13bf6c2d

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

  Stats: 63519 lines in 1098 files changed: 41921 ins; 15397 del; 6201 mod
  Patch: https://git.openjdk.org/jdk/pull/25289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289

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

From alanb at openjdk.org  Wed May 28 14:42:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 May 2025 14:42:53 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v2]
In-Reply-To: <9daRPddZDVKrMkF0OhiJbtPaDhNp3GHWB4wHM3fa9qY=.6724f53f-2abd-43a8-8a17-ac3c187081bb@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <9daRPddZDVKrMkF0OhiJbtPaDhNp3GHWB4wHM3fa9qY=.6724f53f-2abd-43a8-8a17-ac3c187081bb@github.com>
Message-ID: 

On Wed, 28 May 2025 12:46:38 GMT, Rohitash Kumar  wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update license and stylistic improvements

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

> 117: 
> 118:         // Zero in chunks to avoid blocking safepoints for too long
> 119:         long chunkSize = 1024 * 1024;

In the past, the bulk put/get when swapping also used 1MB as the threshold because of TTSP. So I think this value is reasonable. Might be a bit nicer to make it a constant (static final).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2112089754

From lancea at openjdk.org  Wed May 28 15:26:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 May 2025 15:26:03 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 27 May 2025 19:21:45 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying parsing of version parameter.

I think you are in good shape with your last set of changes David

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2875534085

From duke at openjdk.org  Wed May 28 16:10:10 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Wed, 28 May 2025 16:10:10 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v3]
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: 

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

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

  make chunk_size a constant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/03567436..876f5c8b

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

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

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

From duke at openjdk.org  Wed May 28 16:10:10 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Wed, 28 May 2025 16:10:10 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v2]
In-Reply-To: 
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <9daRPddZDVKrMkF0OhiJbtPaDhNp3GHWB4wHM3fa9qY=.6724f53f-2abd-43a8-8a17-ac3c187081bb@github.com>
 
Message-ID: 

On Wed, 28 May 2025 14:40:18 GMT, Alan Bateman  wrote:

>> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update license and stylistic improvements
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 119:
> 
>> 117: 
>> 118:         // Zero in chunks to avoid blocking safepoints for too long
>> 119:         long chunkSize = 1024 * 1024;
> 
> In the past, the bulk put/get when swapping also used 1MB as the threshold because of TTSP. So I think this value is reasonable. Might be a bit nicer to make it a constant (static final).

Thanks for the insight on value of chunk size. And agreed on static final part, I?ve made it a `private static final `constant

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2112268863

From shade at openjdk.org  Wed May 28 16:26:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 May 2025 16:26:52 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v2]
In-Reply-To: 
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <9daRPddZDVKrMkF0OhiJbtPaDhNp3GHWB4wHM3fa9qY=.6724f53f-2abd-43a8-8a17-ac3c187081bb@github.com>
 
 
Message-ID: <_ciJisBPm95eQgD13NwpMGcoAghD9FSTUVtd3GMjV4k=.2036c901-9350-4ccc-bcfb-49d1cff7b4ba@github.com>

On Wed, 28 May 2025 16:07:01 GMT, Rohitash Kumar  wrote:

>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 119:
>> 
>>> 117: 
>>> 118:         // Zero in chunks to avoid blocking safepoints for too long
>>> 119:         long chunkSize = 1024 * 1024;
>> 
>> In the past, the bulk put/get when swapping also used 1MB as the threshold because of TTSP. So I think this value is reasonable. Might be a bit nicer to make it a constant (static final).
>
> Thanks for the insight on value of chunk size. And agreed on static final part, I?ve made it a `private static final `constant

> In the past, the bulk put/get when swapping also used 1MB as the threshold because of TTSP

Oh, TIL. Do you have a pointer where that was? I searched around and cannot find it. We should probably put the constant in the similar place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2112300504

From ogillespie at openjdk.org  Wed May 28 16:43:50 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 28 May 2025 16:43:50 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v2]
In-Reply-To: <_ciJisBPm95eQgD13NwpMGcoAghD9FSTUVtd3GMjV4k=.2036c901-9350-4ccc-bcfb-49d1cff7b4ba@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <9daRPddZDVKrMkF0OhiJbtPaDhNp3GHWB4wHM3fa9qY=.6724f53f-2abd-43a8-8a17-ac3c187081bb@github.com>
 
 
 <_ciJisBPm95eQgD13NwpMGcoAghD9FSTUVtd3GMjV4k=.2036c901-9350-4ccc-bcfb-49d1cff7b4ba@github.com>
Message-ID: 

On Wed, 28 May 2025 16:24:13 GMT, Aleksey Shipilev  wrote:

>> Thanks for the insight on value of chunk size. And agreed on static final part, I?ve made it a `private static final `constant
>
>> In the past, the bulk put/get when swapping also used 1MB as the threshold because of TTSP
> 
> Oh, TIL. Do you have a pointer where that was? I searched around and cannot find it. We should probably put the constant in the similar place.

We have https://github.com/openjdk/jdk8u/blob/master/jdk/src/share/classes/java/nio/Bits.java#L776-L779, at least. Not sure if there are others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2112333241

From shade at openjdk.org  Wed May 28 16:54:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 May 2025 16:54:51 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v2]
In-Reply-To: 
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <9daRPddZDVKrMkF0OhiJbtPaDhNp3GHWB4wHM3fa9qY=.6724f53f-2abd-43a8-8a17-ac3c187081bb@github.com>
 
 
 <_ciJisBPm95eQgD13NwpMGcoAghD9FSTUVtd3GMjV4k=.2036c901-9350-4ccc-bcfb-49d1cff7b4ba@github.com>
 
Message-ID: 

On Wed, 28 May 2025 16:41:36 GMT, Oli Gillespie  wrote:

>>> In the past, the bulk put/get when swapping also used 1MB as the threshold because of TTSP
>> 
>> Oh, TIL. Do you have a pointer where that was? I searched around and cannot find it. We should probably put the constant in the similar place.
>
> We have https://github.com/openjdk/jdk8u/blob/master/jdk/src/share/classes/java/nio/Bits.java#L776-L779, at least. Not sure if there are others.

I see, so that copying threshold was removed by [JDK-8149596](https://bugs.openjdk.org/browse/JDK-8149596) in JDK 9: https://github.com/openjdk/jdk/commit/2255be0267ea036750587e2b9aef11e37d25eace

Which is extra confusing, because I don't think `Unsafe.copyMemory` is immune to TTSP issue as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2112345990

From shade at openjdk.org  Wed May 28 16:54:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 May 2025 16:54:52 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v2]
In-Reply-To: 
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <9daRPddZDVKrMkF0OhiJbtPaDhNp3GHWB4wHM3fa9qY=.6724f53f-2abd-43a8-8a17-ac3c187081bb@github.com>
 
 
 <_ciJisBPm95eQgD13NwpMGcoAghD9FSTUVtd3GMjV4k=.2036c901-9350-4ccc-bcfb-49d1cff7b4ba@github.com>
 
 
Message-ID: <1nUuz2ZS0K8uVNlr4-IVwD5P1zN7z5SCKWF6S9NTYwc=.36d26b3a-c571-4999-8a48-0fee67076dbf@github.com>

On Wed, 28 May 2025 16:49:17 GMT, Aleksey Shipilev  wrote:

>> We have https://github.com/openjdk/jdk8u/blob/master/jdk/src/share/classes/java/nio/Bits.java#L776-L779, at least. Not sure if there are others.
>
> I see, so that copying threshold was removed by [JDK-8149596](https://bugs.openjdk.org/browse/JDK-8149596) in JDK 9: https://github.com/openjdk/jdk/commit/2255be0267ea036750587e2b9aef11e37d25eace
> 
> Which is extra confusing, because I don't think `Unsafe.copyMemory` is immune to TTSP issue as well.

But anyway, I think this shows a better home for the constant and the cleaning code, in `java/nio/Bits.java`. Putting it there would also allow us to later reinstate copying loop, if we see it is a problem as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2112350481

From alexei.olkhovskii at servicenow.com  Wed May 28 17:56:20 2025
From: alexei.olkhovskii at servicenow.com (Alexei Olkhovskii)
Date: Wed, 28 May 2025 17:56:20 +0000
Subject: NIO Socket.read() may not respect the socket timeout
In-Reply-To: 
References: 
 
Message-ID: 

Hi Alan, thanks for response

> Would it be possible to do some digging to say for sure if this happens after StackOverflowError (SOE)?

We saw a thread throwing an SOE while holding a DB connection. Later, there was another thread getting stuck while trying to cleanup a connection. Unfortunately, we haven?t collected the thread/memory dumps and can?t state it with 100% confidence. But everything we see in logs and the code is pointing to the scenario described below.

> Can you confirm you created this to demonstrate your point and isn't representative of what the code is doing?

The code is demonstrating the point, but it comes from real code. It starts with our DB Connection Pool checking the connection has no stale data in its socket buffer before handing it out. If it detects stale data (which was the case) it realizes the connection can?t be trusted and kills it by calling the most brutal API method available: abort(). In MariaDB JDBC driver, abort() is calling its internal method closeSocket():
https://github.com/mariadb-corporation/mariadb-connector-j/blob/2.3.0/src/main/java/org/mariadb/jdbc/internal/protocol/AbstractConnectProtocol.java#L275

Now, for some reason the closeSocket() is trying to ensure the socket buffer is empty by attempting to read a byte from it. To protect from hangs, the driver is setting a 3-msec timeout on the socket:
https://github.com/mariadb-corporation/mariadb-connector-j/blob/2.3.0/src/main/java/org/mariadb/jdbc/internal/protocol/AbstractConnectProtocol.java#L203
The NIO?s read() first tries to protect the operation by obtaining the lock which makes total sense. But the gap is that it tries to acquire the lock w/o any timeout. Since the lock is already held by the compromised thread, our thread also hangs.

As you?ve pointed out, this isn?t a normal or intended scenario. Moreover, NIO has every right and obligation to protect multi-threaded access to the socket.
The only ask is to respect the timeout while doing that. Feels like this can be easily achieved by using tryLock() similarly to accept().

--
Regards, Alexei (team: Data Scale/Dev-Persistence, dept: Platform Engineering, Loc: San Diego, Mgr: Venkata Koya, Teams/MM: alexei.olkhovskii)

From: Alan Bateman 
Date: Tuesday, May 27, 2025 at 22:59
To: Alexei Olkhovskii , nio-dev at openjdk.org 
Subject: Re: NIO Socket.read() may not respect the socket timeout
[External Email]

________________________________

On 27/05/2025 23:50, Alexei Olkhovskii wrote:
Hello,

We?ve ran into a corner-case issue with socket read(). In short, it doesn?t honor socket timeout when trying to acquire the read lock:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L336

  readLock.lock();

In our case one thread obtained a database connection and got stuck in read() (we think because of a StackOverflow).

Would it be possible to do some digging to say for sure if this happens after StackOverflowError (SOE)? There have been a few reports of issues that appear to be lock "corruption" when continuing after SOE and it may be that the reserved stack area for critical sections needs to be re-visited.

As regards the test. Can you confirm you created this to demonstrate your point and isn't representative of what the code is doing? For a TCP/stream connection then having several threads reading from the same connection would require coordination at a high level. If it does arise that one thread is blocked reading and another thread attempts to read from the same connection then it is blocked until the first thread finishes reading. It would be a strange scenario to arise and different to the accept case where it's okay to have concurrently threads attempt to accept connections, they don't interfere.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alan.bateman at oracle.com  Wed May 28 19:04:47 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 28 May 2025 20:04:47 +0100
Subject: NIO Socket.read() may not respect the socket timeout
In-Reply-To: 
References: 
 
 
Message-ID: 

On 28/05/2025 18:56, Alexei Olkhovskii wrote:
>
> Hi Alan, thanks for response
>
> > Would it be possible to do some digging to say for sure if this 
> happens after StackOverflowError (SOE)?
>
> We saw a thread throwing an SOE while holding a DB connection. Later, 
> there was another thread getting stuck while trying to cleanup a 
> connection.
>

This may be an issue with the reserved stack area. There was work done 
in JDK 9 via JEP 270 [1] but I think it needs to be looked at again.

-Alan

[1] https://openjdk.org/jeps/270
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alexei.olkhovskii at servicenow.com  Wed May 28 19:46:57 2025
From: alexei.olkhovskii at servicenow.com (Alexei Olkhovskii)
Date: Wed, 28 May 2025 19:46:57 +0000
Subject: NIO Socket.read() may not respect the socket timeout
In-Reply-To: 
References: 
 
 
 
Message-ID: 

> This may be an issue with the reserved stack area. There was work done in JDK 9 via JEP 270 [1] but I think it needs to be looked at again.

Perhaps https://bugs.openjdk.org/browse/JDK-8318888 is also relevant.
But regardless of the reason the other thread is holding the lock, don?t you think the socket timeout should be respected for read(), connect(), etc?

--
Regards, Alexei

From: Alan Bateman 
Date: Wednesday, May 28, 2025 at 12:05
To: Alexei Olkhovskii , nio-dev at openjdk.org 
Subject: Re: NIO Socket.read() may not respect the socket timeout
[External Email]

________________________________
On 28/05/2025 18:56, Alexei Olkhovskii wrote:

Hi Alan, thanks for response

> Would it be possible to do some digging to say for sure if this happens after StackOverflowError (SOE)?

We saw a thread throwing an SOE while holding a DB connection. Later, there was another thread getting stuck while trying to cleanup a connection.

This may be an issue with the reserved stack area. There was work done in JDK 9 via JEP 270 [1] but I think it needs to be looked at again.

-Alan

[1] https://openjdk.org/jeps/270
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prr at openjdk.org  Wed May 28 20:55:03 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:03 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
References: 
 
 <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
Message-ID: 

On Mon, 26 May 2025 07:55:52 GMT, Magnus Ihse Bursie  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:
> 
>> 88:                 printKey(e);
>> 89:                 int keychar = e.getKeyChar();
>> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b
> 
> @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

You are right, that's a typo. Keep your change.
And I don't know why the code uses literal 27 instead of KeyEvent.VK_ESCAPE .. but that's not your problem.

https://docs.oracle.com/en/java/javase/21/docs/api/constant-values.html#java.awt.event.KeyEvent.VK_ESCAPE

> test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:
> 
>> 186:                     +          "\"After\" lists.\n"
>> 187:                     + "              Added printers are highlighted with "
>> 188:                     +               "green color, removed ones \u2014 with "
> 
> @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.
> 
> Do you still want me to revert it?

I agree. Keep your change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112722311
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112731040

From prr at openjdk.org  Wed May 28 20:55:04 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:04 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
References: 
 
 <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
Message-ID: 

On Mon, 26 May 2025 08:07:19 GMT, Magnus Ihse Bursie  wrote:

>> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
>> 
>>> 61: 
>>> 62:     private static final String INSTRUCTIONS =
>>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
>> 
>> I really don't like these tests being changed. It isn't part of the JDK build.
>> People compile these in all sorts of locales.
>> Please revert all the changes in the client tests.
>
> Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.
> 
> The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?
> 
> Let me know if you still want me to revert it.

I'd like this reverted.
People *build* these tests in their local repos using javac and whatever their locale is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112728971

From msheppar at openjdk.org  Wed May 28 23:16:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 28 May 2025 23:16:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 28 May 2025 11:13:12 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/0671309d...cf179f7d

her are few file with IOException, UnknownHostException and MalformedURLException, which are worth reviewing form Exception that may have been missed

open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java
Ln 562



open/src/java.base/share/classes/sun/security/x509/IPAddressName.java

open/src/java.base/share/classes/sun/security/x509/URIName.java

open/src/java.base/share/classes/sun/security/x509/RDN.java

open/src/java.base/share/classes/java/util/jar/JarFile.java


UnknownHostException

open/src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java

open/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java


MalformedURLException

open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java

open/src/java.base/share/classes/java/net/URL.java  ? Invalid port

open/src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java

open/src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java

open/src/java.rmi/share/classes/java/rmi/Naming.java

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2917817454

From michaelm at openjdk.org  Thu May 29 09:02:56 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 09:02:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 28 May 2025 23:13:21 GMT, Mark Sheppard  wrote:

> here are a few files with IOException, UnknownHostException and MalformedURLException, which are worth reviewing for Exception that may have been missed
> 
> IOEXception:
> 
> open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java Ln 562
> 
> open/src/java.base/share/classes/sun/security/x509/IPAddressName.java
> 
> open/src/java.base/share/classes/sun/security/x509/URIName.java
> 
> open/src/java.base/share/classes/sun/security/x509/RDN.java
> 
> open/src/java.base/share/classes/java/util/jar/JarFile.java
> 
> UnknownHostException
> 
> open/src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java
> 
> open/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java
> 
> MalformedURLException
> 
> open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java
> 
> open/src/java.base/share/classes/java/net/URL.java ? Invalid port
> 
> open/src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java
> 
> open/src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java
> 
> open/src/java.rmi/share/classes/java/rmi/Naming.java

Thanks, I will take another look at all these cases and update any that I agree need to be included.

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2918771547

From michaelm at openjdk.org  Thu May 29 09:02:55 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 09:02:55 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 26 May 2025 20:39:51 GMT, Mark Sheppard  wrote:

> You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt a builder pattern for the creation of the filter exceptions, for example
> 
> FilteredExceptionBuilder / EnhancedExceptionBuilder.
> 
> It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder.
> 
> EnhancedExceptionBuilder::class() ::exceptionMessage() ::port() ::hostname() ::userDetails() ::filterPolicy()

We've been through so many iterations at this stage, that I think what we've landed on is reasonable and probably most importantly, concise such that it's not overly intrusive at the call sites.

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2918770154

From duke at openjdk.org  Thu May 29 13:57:29 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Thu, 29 May 2025 13:57:29 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v4]
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: <7Z3trbZIPTlOzoi3P-A420O5-g4GidVKJraaQ2IjUd8=.0bf72d8b-5721-4ba8-96d0-4030260d4083@github.com>

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:

 - Bump up copyright year for Bits.java
 - move chunked set logic to java/nio/Bits.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/876f5c8b..13cbbaaf

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

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

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

From duke at openjdk.org  Thu May 29 14:29:43 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Thu, 29 May 2025 14:29:43 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v5]
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: 

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

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

  Remove redundant comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/13cbbaaf..17cce92c

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

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

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

From michaelm at openjdk.org  Thu May 29 14:35:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 14:35:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

  Additional callsites identified by Mark S.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/cf179f7d..34f20c9a

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

  Stats: 79 lines in 9 files changed: 27 ins; 0 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From dfuchs at openjdk.org  Thu May 29 17:10:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 May 2025 17:10:04 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional callsites identified by Mark S.

src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 566:

> 564:                                         filterNonSocketInfo(url.getHost())
> 565:                                             .prefixWith("should be <")
> 566:                                             .suffixWith(">")));

Suggestion:

        throw new IOException(formatMsg("Wrong HTTPS hostname%s",
                                        filterNonSocketInfo(url.getHost())
                                            .prefixWith(": should be <")
                                            .suffixWith(">")));

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 560:

> 558:         if (isa.isUnresolved()) {
> 559:             throw new UnknownHostException(
> 560:                 formatMsg("%s", filterNonSocketInfo(isa.getHostName())));

Suggestion:

                formatMsg(filterNonSocketInfo(isa.getHostName())));

src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java line 99:

> 97:             close();
> 98:             throw new UnknownHostException(
> 99:                 formatMsg("%s", filterNonSocketInfo(remote.toString())));

Suggestion:

            throw new UnknownHostException(
                formatMsg(filterNonSocketInfo(remote.toString())));

src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java line 125:

> 123:     protected MalformedURLException newInvalidURISchemeException(String uri) {
> 124:         return new MalformedURLException(formatMsg("Not an LDAP URL: %s",
> 125:                                                    filterNonSocketInfo(uri)));

Suggestion:

        return new MalformedURLException(formatMsg("Not an LDAP URL%s",
                                                   filterNonSocketInfo(uri).prefixWith(": ")));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 238:

> 236: 
> 237:     private MalformedURLException newMalformedURLException(String prefix, String msg) {
> 238:         return new MalformedURLException(formatMsg(prefix + " %s", filterNonSocketInfo(msg)));

Suggestion:

        return new MalformedURLException(prefix + formatMsg(filterNonSocketInfo(msg).withPrefix(prefix.isEmpty()? "" : ": "));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 250:

> 248:                 URI u = new URI(uri);
> 249:                 scheme = u.getScheme();
> 250:                 if (scheme == null) throw newMalformedURLException("Invalid URI:", uri);

Suggestion:

                if (scheme == null) throw newMalformedURLException("Invalid URI", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 262:

> 260:                     if (!hostport.equals(auth)) {
> 261:                         // throw if we have user info or regname
> 262:                         throw newMalformedURLException("unsupported authority:", auth);

Suggestion:

                        throw newMalformedURLException("unsupported authority", auth);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 271:

> 269:                 if (u.getRawFragment() != null) {
> 270:                     if (!acceptsFragment()) {
> 271:                         throw newMalformedURLException("URI fragments not supported:", uri);

Suggestion:

                        throw newMalformedURLException("URI fragments not supported", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 308:

> 306:         int fmark = uri.indexOf('#');
> 307:         if (i < 0 || slash > 0 && i > slash || qmark > 0 && i > qmark || fmark > 0 && i > fmark) {
> 308:             throw newMalformedURLException("Invalid URI:", uri);

Suggestion:

            throw newMalformedURLException("Invalid URI", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 312:

> 310:         if (fmark > -1) {
> 311:             if (!acceptsFragment()) {
> 312:                 throw newMalformedURLException("URI fragments not supported:", uri);

Suggestion:

                throw newMalformedURLException("URI fragments not supported", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 358:

> 356:                     String ui = u.getRawUserInfo();
> 357:                     if (ui != null) {
> 358:                         throw newMalformedURLException("user info not supported in authority:", ui);

Suggestion:

                        throw newMalformedURLException("user info not supported in authority", ui);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 361:

> 359:                     }
> 360:                     if (!"/".equals(p)) {
> 361:                         throw newMalformedURLException("invalid authority:", auth);

Suggestion:

                        throw newMalformedURLException("invalid authority", auth);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 364:

> 362:                     }
> 363:                     if (q != null) {
> 364:                         throw newMalformedURLException("invalid trailing characters in authority: ?", q);

Suggestion:

                        throw new MalformedURLException("invalid trailing characters in authority: ?" + formatMsg(filterNonSocketInfo(q)));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 374:

> 372:                         // throw if we have user info or regname
> 373:                         throw newMalformedURLException("Authority component is not server-based, " +
> 374:                                               "or contains user info. Unsupported authority:", auth);

Suggestion:

                                              "or contains user info. Unsupported authority", auth);

src/java.rmi/share/classes/java/rmi/Naming.java line 227:

> 225: 
> 226:     private static MalformedURLException newMalformedURLException(String prefix, String msg) {
> 227:         return new MalformedURLException(formatMsg(prefix + " %s", filterNonSocketInfo(msg)));

Suggestion:

        return new MalformedURLException(prefix + formatMsg(filterNonSocketInfo(msg).prefixWith(": "));

src/java.rmi/share/classes/java/rmi/Naming.java line 250:

> 248:              */
> 249:             MalformedURLException mue = newMalformedURLException(
> 250:                 "invalid URL String:", str);

Suggestion:

                "invalid URL String", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 282:

> 280:         if (uri.isOpaque()) {
> 281:             throw newMalformedURLException(
> 282:                 "not a hierarchical URL:", str);

Suggestion:

                "not a hierarchical URL", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 286:

> 284:         if (uri.getFragment() != null) {
> 285:             throw newMalformedURLException(
> 286:                 "invalid character, '#', in URL name:", str);

Suggestion:

                "invalid character, '#', in URL name", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 289:

> 287:         } else if (uri.getQuery() != null) {
> 288:             throw newMalformedURLException(
> 289:                 "invalid character, '?', in URL name:", str);

Suggestion:

                "invalid character, '?', in URL name", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 292:

> 290:         } else if (uri.getUserInfo() != null) {
> 291:             throw newMalformedURLException(
> 292:                 "invalid character, '@', in URL host:", str);

Suggestion:

                "invalid character, '@', in URL host", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 296:

> 294:         String scheme = uri.getScheme();
> 295:         if (scheme != null && !scheme.equals("rmi")) {
> 296:             throw newMalformedURLException("invalid URL scheme:", str);

Suggestion:

            throw new MalformedURLException(formatMsg("invalid URL scheme%s", filterNonSocketInfo(str).prefixWith(": ").replaceWith(": rmi"));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114314118
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114338001
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114341371
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114325981
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114336092
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114343715
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114344189
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114344732
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114349684
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114360771
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114361269
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114361808
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114372438
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114373811
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114380353
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381257
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381615
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381991
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114382430
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114382678
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114383025

From alan.bateman at oracle.com  Thu May 29 17:39:54 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Thu, 29 May 2025 18:39:54 +0100
Subject: NIO Socket.read() may not respect the socket timeout
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 



On 28/05/2025 20:46, Alexei Olkhovskii wrote:
>
> > This may be an issue with the reserved stack area. There was work done 
> in JDK 9 via JEP 270 [1] but I think it needs to be looked at again.
>
> Perhaps https://bugs.openjdk.org/browse/JDK-8318888 is also relevant.
>

Yes, there are a few reports of issues when continuing after SOE.


> But regardless of the reason the other thread is holding the lock, 
> don?t you think the socket timeout should be respected for read(), 
> connect(), etc?
>

The connect method is only allowed once. It would be strange to create 
an unconnected Socket and then attempt to have 2 threads invoke connect. 
The second attempt must fail with SocketException (it will be 
"Connection in progress" or "Socket closed"). You are right that the 
second attempt will block, maybe beyond the connect timeout it 
specifies, before it throws the SocketException. I don't think this is 
worth spending time on as there is impossible for the second connect to 
succeed.

It's hard to know if there if there is a case where concurrent reads 
from the same TCP/socket stream make sense. At one point it was possible 
to have a Socket to a UDP socket but that mis-feature is deprecated a 
long time ago. If several threads are reading from the same stream then 
it requires coordination at a higher level, something that understands 
the protocol, meaning the lock contention will be further up the stack. 
If there is a protocol where it's possible to do something sensible when 
reading subsets of bytes, and with different timeouts, or code handling 
SocketTimeoutException then maybe your point could be looked. For now, I 
think the issue here is the "lock corruption" and we need to understand 
this a bit more. I'd prefer not use that to justify doing something to 
help a workaround when it does happen.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prr at openjdk.org  Thu May 29 19:08:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 19:08:54 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie  wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

Approving client changes

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2879326497

From bpb at openjdk.org  Thu May 29 19:10:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 19:10:46 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v14]
In-Reply-To: 
References: 
Message-ID: <6JakAvYfDIFLQHI8MwxCjvEl-4MR4rQmJzJNGytPQIw=.689b5a9f-c0c6-4dea-8e6b-b668b999e8c0@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 14 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - ... and 4 more: https://git.openjdk.org/jdk/compare/79aff26c...95ce13fb

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=13
  Stats: 1540 lines in 93 files changed: 774 ins; 668 del; 98 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 bpb at openjdk.org  Thu May 29 19:55:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 19:55:03 GMT
Subject: RFR: 8357847: WindowsAsynchronousFileChannelImpl should support FFM
 Buffers
Message-ID: 

Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

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

Commit messages:
 - 8357847: WindowsAsynchronousFileChannelImpl should support FFM Buffers

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

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

From alexei.olkhovskii at servicenow.com  Thu May 29 21:20:19 2025
From: alexei.olkhovskii at servicenow.com (Alexei Olkhovskii)
Date: Thu, 29 May 2025 21:20:19 +0000
Subject: NIO Socket.read() may not respect the socket timeout
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

> It's hard to know if there if there is a case where concurrent reads from the same TCP/socket stream make sense ... If there is a protocol where it's possible to do something sensible when reading subsets of bytes, and with different timeouts, or code handling SocketTimeoutException then maybe your point could be looked ...

Yes, a conscious design involving concurrent Socket use would be a strange thing, no argument there. Also, your point about connect() makes total sense.

Going back to read(), what would be the way out of the situation for the API users? The app has detected stale data in the socket buffer and tries to clean things up. It isn?t aware the other reader is still alive and calls JDBC abort(). The JDBC spec allows Connection sharing, the driver isn?t even obliged to check for concurrency. Sure, it is doing a questionable read(), but while taking the timeout precautions.
In this situation NIO is the only player aware of the other reader. Which brings us to the choice: try to eliminate the reason the other player is holding the lock (which sounds like an uphill battle) or behave transparently to the lock presence: wait for the timeout interval and return -1 like if there was no data. Besides, the lock is an internal library mechanism whose existence has only surfaced accidently.
>From the API user standpoint, the second option sounds simpler to handle. Not saying we ever will but should someone want to code around a hund read, that?d bring a lot of complexity.

> I'd prefer not use that to justify doing something to help a workaround when it does happen.

Please note that we?d not make the situation worse than today, should somebody attempt to call read() concurrently. The logical difference would be ?the call returned no data because **there is** no data? vs ?the call returned no data because somebody else is reading it and we?ve timed out? (as opposed to today?s ?wait for an uncertain interval till the other party has finished their read?).

--
Regards, Alexei

From: Alan Bateman 
Date: Thursday, May 29, 2025 at 10:40
To: Alexei Olkhovskii , nio-dev at openjdk.org 
Subject: Re: NIO Socket.read() may not respect the socket timeout
[External Emai

________________________________

On 28/05/2025 20:46, Alexei Olkhovskii wrote:
> This may be an issue with the reserved stack area. There was work done in JDK 9 via JEP 270 [1] but I think it needs to be looked at again.
Perhaps https://bugs.openjdk.org/browse/JDK-8318888 is also relevant.

Yes, there are a few reports of issues when continuing after SOE.



But regardless of the reason the other thread is holding the lock, don?t you think the socket timeout should be respected for read(), connect(), etc?

The connect method is only allowed once. It would be strange to create an unconnected Socket and then attempt to have 2 threads invoke connect. The second attempt must fail with SocketException (it will be "Connection in progress" or "Socket closed"). You are right that the second attempt will block, maybe beyond the connect timeout it specifies, before it throws the SocketException. I don't think this is worth spending time on as there is impossible for the second connect to succeed.

It's hard to know if there if there is a case where concurrent reads from the same TCP/socket stream make sense. At one point it was possible to have a Socket to a UDP socket but that mis-feature is deprecated a long time ago. If several threads are reading from the same stream then it requires coordination at a higher level, something that understands the protocol, meaning the lock contention will be further up the stack. If there is a protocol where it's possible to do something sensible when reading subsets of bytes, and with different timeouts, or code handling SocketTimeoutException then maybe your point could be looked. For now, I think the issue here is the "lock corruption" and we need to understand this a bit more. I'd prefer not use that to justify doing something to help a workaround when it does happen.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bpb at openjdk.org  Thu May 29 23:44:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 23:44:07 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
Message-ID: 

Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

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

Commit messages:
 - 8357425: (fs) SecureDirectoryStream setPermissions should use fchmodat

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

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

From bpb at openjdk.org  Thu May 29 23:44:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 23:44:07 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 May 2025 23:37:26 GMT, Brian Burkhalter  wrote:

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

The `jdk_nio` tests pass on Linux and macOS in the CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2920816849

From alanb at openjdk.org  Fri May 30 05:37:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 05:37:51 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 May 2025 23:37:26 GMT, Brian Burkhalter  wrote:

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java line 423:

> 421:                 else if (fchmodatNoFollowSupported())
> 422:                     fchmodat(dfd, file, UnixFileModeAttribute.toUnixMode(perms),
> 423:                              AT_SYMLINK_NOFOLLOW);

The 4 cases look okay. If you adds`int mode = UnixFileModeAttribute.toUnixMode(perms)` then it would avoid the repeated code and avoid the line splits, just makes it easier to read.

src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java line 434:

> 432:                 }
> 433:             } catch (UnixException x) {
> 434:                 x.rethrowAsIOException(file);

'file' will be null when changing the directory's permission, can you double check that case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25534#discussion_r2115172005
PR Review Comment: https://git.openjdk.org/jdk/pull/25534#discussion_r2115172441

From alanb at openjdk.org  Fri May 30 05:40:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 05:40:50 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 May 2025 23:37:26 GMT, Brian Burkhalter  wrote:

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

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

> 815:     const char* path = (const char*)jlong_to_ptr(pathAddress);
> 816: 
> 817:     RESTARTABLE(fchmodat((int)fd, path, (mode_t)mode, (int)flag), err);

@MBaesken Do you want to confirm that this will build/run on AIX?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25534#discussion_r2115175107

From alanb at openjdk.org  Fri May 30 05:43:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 05:43:50 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 May 2025 19:50:58 GMT, Brian Burkhalter  wrote:

> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

@bplb This will need tests to exercise the read/write methods with buffers that a views on memory segments allocated from automatic and shared arenas. I think we also need to check that we have tests to ensure that UOE is thrown for thread confined arenas.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2921288565

From alanb at openjdk.org  Fri May 30 06:00:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 06:00:51 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 May 2025 19:50:58 GMT, Brian Burkhalter  wrote:

> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 452:

> 450:                 buf = dst;
> 451:                 address = ((DirectBuffer)dst).address() + pos;
> 452:                 IOUtil.acquireScope(dst, true);

I assume we'll have to change this to use IOUtil.bufferAddress(dst), and after the acquire.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2115194676

From mbaesken at openjdk.org  Fri May 30 07:57:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 May 2025 07:57:58 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 May 2025 23:37:26 GMT, Brian Burkhalter  wrote:

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

Hi Alan, thanks for reaching out.
> Do you want to confirm that this will build/run on AIX?
I can confirm that it builds on AIX.
Regarding running, the test that is part of the change it linux/macOS only.
When I add aix to the test  (test/jdk/java/nio/file/DirectoryStream/SecureDS.java)  I get
`TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: SecureDirectoryStream not supported.`
but I guess this is expected currently because the test is linux/mac only ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2921528988

From alanb at openjdk.org  Fri May 30 08:16:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 08:16:50 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 30 May 2025 07:55:02 GMT, Matthias Baesken  wrote:

> > When I add aix to the test  (test/jdk/java/nio/file/DirectoryStream/SecureDS.java)  I get
> > `TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: SecureDirectoryStream not supported.`
> > but I guess this is expected currently because the test is linux/mac only ?

Thanks for checking. The newDirectoryStream methods return a SecureDirectoryStream on platforms that support all the "at" syscalls (list is in UnixNativeDispatcher.c) so I think it means that it is not supported on AIX because some of the "at" calls don't exist. In that case, once it builds it is okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2921571564

From michaelm at openjdk.org  Fri May 30 09:01:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:01:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v14]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

  Apply suggestions from code review
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/34f20c9a..cf5233c1

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

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

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

From michaelm at openjdk.org  Fri May 30 09:01:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:01:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional callsites identified by Mark S.

Thanks for the suggestions. I have committed all of them except for two. One, I will modify in another way.

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2921687319

From michaelm at openjdk.org  Fri May 30 09:39:36 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:39:36 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v15]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - typo in suggestions and other issues
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Additional callsites identified by Mark S.
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - ... and 24 more: https://git.openjdk.org/jdk/compare/e33eeeea...462ee011

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=14
  Stats: 984 lines in 47 files changed: 711 ins; 101 del; 172 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From michaelm at openjdk.org  Fri May 30 10:32:57 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 10:32:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 30 May 2025 09:39:36 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - typo in suggestions and other issues
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Additional callsites identified by Mark S.
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e33eeeea...462ee011

The last change to java.net.HostPortrange (renaming the constructor parameter) has caused a problem. The parameter is hiding a field of the same name. I need to fix that now.

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2921954327

From alanb at openjdk.org  Fri May 30 10:40:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:40:29 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not released
 when FJP common pool threads clears thread locals
Message-ID: 

A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.

For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.

The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.

Testing 1-5. Performance testing ongoing.

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

Commit messages:
 - Remove stray file
 - Update
 - Merge branch 'master' into JDK-8357637
 - Merge branch 'master' into JDK-8357637
 - Merge branch 'master' into JDK-8357637
 - Cleanup/review feedback
 - Merge branch 'master' into JDK-8357637
 - Merge branch 'master' into JDK-8357637
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/25457/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25457&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357637
  Stats: 149 lines in 9 files changed: 89 ins; 37 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25457/head:pull/25457

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

From vklang at openjdk.org  Fri May 30 10:40:30 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 30 May 2025 10:40:30 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: 
References: 
Message-ID: 

On Mon, 26 May 2025 17:16:02 GMT, Alan Bateman  wrote:

> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
> 
> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
> 
> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
> 
> Testing 1-5. Performance testing ongoing.

@AlanBateman I think this approach is a good step in the right direction here.

src/java.base/share/classes/java/lang/InheritableThreadLocal.java line 95:

> 93:     void createMap(Thread t, T firstValue) {
> 94:         var map = new ThreadLocalMap(this, firstValue);
> 95:         t.setInheritableThreadLocals(map);

Stylistic suggestion:

Suggestion:

        t.setInheritableThreadLocals(new ThreadLocalMap(this, firstValue));

src/java.base/share/classes/java/lang/Thread.java line 246:

> 244:         volatile boolean daemon;
> 245:         volatile int threadStatus;
> 246:         ThreadLocal.ThreadLocalMap terminatingThreadLocals;

I think it's worth documenting the memory safety aspects of this field.

src/java.base/share/classes/java/lang/ThreadLocal.java line 284:

> 282:      */
> 283:     ThreadLocalMap getMap(Thread t) {
> 284:         if (this instanceof TerminatingThreadLocal) {

Would it make sense to override `getMap` in TerminatingThreadLocal instead?

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 549:

> 547:     void removeCarrierThreadLocal(CarrierThreadLocal local);
> 548: 
> 549:     /**

Copyright update?

src/java.base/share/classes/jdk/internal/misc/TerminatingThreadLocal.java line 82:

> 80:      */
> 81:     public static void register(TerminatingThreadLocal tl) {
> 82:         if (tl != REGISTRY) {

Would this happen in any well-behaved application? If not, might be better to throw an exception? ?

src/java.base/share/classes/jdk/internal/misc/TerminatingThreadLocal.java line 96:

> 94: 
> 95:     /**
> 96:      * A per-terminating-thread registry of TerminatingThreadLocal(s) that have been

Perhaps "A per-platform-thread registry ..."?

src/java.base/share/classes/sun/nio/ch/IOVecWrapper.java line 83:

> 81:             if (wrapper != null) {
> 82:                 wrapper.vecArray.free();
> 83:                 cache[0] = null;

Perhaps null it out before calling free()? (in case free() fails)

test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 194:

> 192:                 assertNull(tl.get());
> 193:                 assertEquals(ttl.get(), ttlValue);
> 194:             } catch (Exception ex) {

Perhaps safer with catching Throwable?if there are any Errors thrown.

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

PR Comment: https://git.openjdk.org/jdk/pull/25457#issuecomment-2916569305
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2112057817
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2109017596
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2109025118
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2112062254
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115588231
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2109416867
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2109418667
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2112066646

From duke at openjdk.org  Fri May 30 10:40:30 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 30 May 2025 10:40:30 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 27 May 2025 12:14:16 GMT, Viktor Klang  wrote:

>> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
>> 
>> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
>> 
>> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
>> 
>> Testing 1-5. Performance testing ongoing.
>
> src/java.base/share/classes/java/lang/ThreadLocal.java line 284:
> 
>> 282:      */
>> 283:     ThreadLocalMap getMap(Thread t) {
>> 284:         if (this instanceof TerminatingThreadLocal) {
> 
> Would it make sense to override `getMap` in TerminatingThreadLocal instead?

`TerminatingThreadLocal` is?located in?the?`jdk.internal.misc` package, so?that?s?not a?possibility without?introducing `module?protected` visibility, which?was?decided against?during?development of?**Project?Jigsaw**, as?it?would further?complicate the?already?complex method?resolution?rules.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2111405993

From alanb at openjdk.org  Fri May 30 10:40:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:40:30 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 28 May 2025 14:27:40 GMT, Viktor Klang  wrote:

>> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
>> 
>> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
>> 
>> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
>> 
>> Testing 1-5. Performance testing ongoing.
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 549:
> 
>> 547:     void removeCarrierThreadLocal(CarrierThreadLocal local);
>> 548: 
>> 549:     /**
> 
> Copyright update?

It's already up to date so no change.

> src/java.base/share/classes/jdk/internal/misc/TerminatingThreadLocal.java line 82:
> 
>> 80:      */
>> 81:     public static void register(TerminatingThreadLocal tl) {
>> 82:         if (tl != REGISTRY) {
> 
> Would this happen in any well-behaved application? If not, might be better to throw an exception? ?

It's just a consequence of the registry being a ttl, we either check it here or in set, it's more local here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115634840
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115633931

From alanb at openjdk.org  Fri May 30 10:43:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:43:55 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 27 May 2025 12:10:19 GMT, Viktor Klang  wrote:

>> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
>> 
>> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
>> 
>> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
>> 
>> Testing 1-5. Performance testing ongoing.
>
> src/java.base/share/classes/java/lang/Thread.java line 246:
> 
>> 244:         volatile boolean daemon;
>> 245:         volatile int threadStatus;
>> 246:         ThreadLocal.ThreadLocalMap terminatingThreadLocals;
> 
> I think it's worth documenting the memory safety aspects of this field.

Comment added to make it clear that it is maintained by the TL class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115642472

From michaelm at openjdk.org  Fri May 30 10:44:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 10:44:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

  Fixed problem with j.n.HostPortRange

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/462ee011..3eec6c03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=14-15

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

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

From alanb at openjdk.org  Fri May 30 10:47:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:47:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed problem with j.n.HostPortRange

src/java.base/share/classes/sun/net/www/protocol/jmod/Handler.java line 50:

> 48:         if (index == -1)
> 49:             throw new MalformedURLException(
> 50:                 formatMsg("no !/ found in url spec%s", filterJarName(s).prefixWith(": ")));

JMOD files can only be used at compile time and link time. So I think you can drop the changes jmod stream handler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2115650070

From vyazici at openjdk.org  Fri May 30 11:12:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 11:12:15 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
Message-ID: 

Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.

`stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

Commit messages:
 - Revert more superfluous changes
 - Fix code typo
 - Discard changes unrelated with core libraries
 - Revert superfluous changes
 - Revert changes to 3rd parties in `com/sun/org/apache`
 - Revert `PandocFilter` changes
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357995
  Stats: 65 lines in 15 files changed: 16 ins; 7 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

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

From vyazici at openjdk.org  Fri May 30 12:02:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 12:02:37 GMT
Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked*
 methods
Message-ID: 

Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197) (which implements JavaDoc improvement and precautionary naming for certain unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are found to be incorrect. See the JBS issue for details on the followed evaluation process.

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

Commit messages:
 - Revert incorrect JLA renamings

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

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

From vklang at openjdk.org  Fri May 30 12:29:53 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 30 May 2025 12:29:53 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: 
References: 
Message-ID: <-jJFOjTCpG8BFv11gZ8M63PhLH4izukA5Hx2EfaCdxo=.612568ac-26fc-4a2d-b07a-e2c502cdd7c2@github.com>

On Mon, 26 May 2025 17:16:02 GMT, Alan Bateman  wrote:

> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
> 
> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
> 
> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
> 
> Testing 1-5. Performance testing ongoing.

Great work on this one, Alan.

I presume this has gone through the needed tiers for testing?

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

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25457#pullrequestreview-2881204899

From alanb at openjdk.org  Fri May 30 13:07:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 13:07:54 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v5]
In-Reply-To: 
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 
Message-ID: <7OGRS3HDffEZa2_AldHLrmo0ujN6PcxYzrjodi3yYVo=.f84f2b01-a7ee-4d0a-84f7-496c7c71e117@github.com>

On Thu, 29 May 2025 14:29:43 GMT, Rohitash Kumar  wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant comment

Moving it to Bits.setMemory looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2922346431

From mullan at openjdk.org  Fri May 30 13:34:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 May 2025 13:34:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed problem with j.n.HostPortRange

src/java.base/share/conf/security/java.security line 1282:

> 1280: # Exception messages may include potentially sensitive information such as file
> 1281: # names, host names, or port numbers. By default, socket related exceptions
> 1282: # have this information restricted (meaning the sensitive details are removed).

I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2115938656

From weijun at openjdk.org  Fri May 30 13:46:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 May 2025 13:46:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: 
References: 
Message-ID: 

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici  wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2922441338

From vyazici at openjdk.org  Fri May 30 14:01:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 14:01:55 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 30 May 2025 13:44:08 GMT, Weijun Wang  wrote:

> Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.

Required changes are pretty minimal ? passing `System.getProperty("stdin.encoding")` as an argument to the ctor. I doubt adding an extra layer of indirection (plus the need for changes in `@build` and `@library` tags) will worth it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2922477202

From alanb at openjdk.org  Fri May 30 14:08:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 14:08:02 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 27 May 2025 19:21:45 GMT, David Beaumont  wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying parsing of version parameter.

API docs + update to ZipFileSystem looks good. Test coverage looks good too.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2881470041

From alanb at openjdk.org  Fri May 30 14:27:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 14:27:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: 
References: 
Message-ID: 

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici  wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

test/jdk/com/sun/tools/attach/Application.java line 40:

> 38: 
> 39:         try (BufferedReader br = new BufferedReader(new InputStreamReader(
> 40:                 System.in, System.getProperty("stdin.encoding")))) {

This "application" is launched by the test so connected to the parent process rather than the console.

test/jdk/java/lang/ProcessHandle/JavaChild.java line 315:

> 313:                         // children and wait for each to exit
> 314:                         sendResult(action, "start");
> 315:                         try (Reader reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));

I didn't study the test closely but I think this is another case where a child process is launched so System.in is connected to the parent rather than the console.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2116027806
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2116031061

From michaelm at openjdk.org  Fri May 30 14:52:56 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 14:52:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 May 2025 13:32:08 GMT, Sean Mullan  wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed problem with j.n.HostPortRange
>
> src/java.base/share/conf/security/java.security line 1282:
> 
>> 1280: # Exception messages may include potentially sensitive information such as file
>> 1281: # names, host names, or port numbers. By default, socket related exceptions
>> 1282: # have this information restricted (meaning the sensitive details are removed).
> 
> I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.

Fair point. I think we can make this clearer with a small addition. I propose to add the following sentence after the one starting "By default ..."

# Exception messages relating to Jar files and exceptions containing user
# identity information are also restricted by default.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2116074735

From bpb at openjdk.org  Fri May 30 15:52:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 15:52:51 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: 
References: 
 
Message-ID: <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>

On Fri, 30 May 2025 05:41:05 GMT, Alan Bateman  wrote:

> his will need tests to exercise the read/write methods with buffers that a views on memory segments allocated from automatic and shared arenas.

There is already testing on automatic arenas, I believe, and passing in a shared arena resulted in a UOE.

> I think we also need to check that we have tests to ensure that UOE is thrown for thread confined arenas.

I observed this UOE already so that should be simple.

> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 452:
> 
>> 450:                 buf = dst;
>> 451:                 address = ((DirectBuffer)dst).address() + pos;
>> 452:                 IOUtil.acquireScope(dst, true);
> 
> I assume we'll have to change this to use IOUtil.bufferAddress(dst), and after the acquire.

Noted.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2922755683
PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2116171482

From alanb at openjdk.org  Fri May 30 15:56:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 15:56:51 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>
References: 
 
 <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>
Message-ID: 

On Fri, 30 May 2025 15:50:40 GMT, Brian Burkhalter  wrote:

> There is already testing on automatic arenas, I believe, and passing in a shared arena resulted in a UOE.

We should be able to use a buffer that is a view of memory segment allocated from shared arena, only the confined case should throw UOE.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2922765300

From bpb at openjdk.org  Fri May 30 15:58:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 15:58:52 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 May 2025 08:13:53 GMT, Alan Bateman  wrote:

> The newDirectoryStream methods return a SecureDirectoryStream on platforms that support all the "at" syscalls (list is in UnixNativeDispatcher.c)

Note that I did not add `fchmodat` to this list of capabilities for all the "at" syscalls as it appears to be supported at least on all configurations [certified for Oracle JDK 24](https://bugs.openjdk.org/browse/JDK-8357425?focusedId=14782741&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14782741). I am not sure about AIX however.

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2922769346

From bpb at openjdk.org  Fri May 30 16:02:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 16:02:51 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 May 2025 23:37:26 GMT, Brian Burkhalter  wrote:

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

It is supported on [AIX 7.1.0](https://www.ibm.com/docs/en/aix/7.1.0?topic=c-chmod-fchmod-fchmodat-subroutine) which dates from September 2010.

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2922779696

From alanb at openjdk.org  Fri May 30 16:11:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 16:11:50 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 30 May 2025 15:56:03 GMT, Brian Burkhalter  wrote:

> Note that I did not add `fchmodat` to this list of capabilities for all the "at" syscalls as it appears to be supported at least on all configurations [certified for Oracle JDK 24](https://bugs.openjdk.org/browse/JDK-8357425?focusedId=14782741&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14782741). I am not sure about AIX however.

Right, and another option to be to not introduce a new capability but it have it covered by SUPPORTS_OPENAT.

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2922798371

From bpb at openjdk.org  Fri May 30 16:22:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 16:22:51 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: 
References: 
 
 <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>
 
Message-ID: 

On Fri, 30 May 2025 15:54:34 GMT, Alan Bateman  wrote:

> We should be able to use a buffer that is a view of memory segment allocated from shared arena, only the confined case should throw UOE.

I ran into this in testing:

    public long address() {
        MemorySessionImpl session = session();
        if (session != null) {
            if (session.ownerThread() == null && session.isCloseable()) {
                throw new UnsupportedOperationException("ByteBuffer derived from closeable shared sessions not supported");
            }
 ```
in `Direct-X-Buffer.java.template` when using the result of `Arena.ofShared`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2922822498

From bpb at openjdk.org  Fri May 30 16:24:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 16:24:50 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <7BllUHR-zPK4jjYtA_7caaEDVbXXdD4x5OcFYmhSacY=.fbb80df7-199a-402f-9794-92dcae4155f6@github.com>

On Fri, 30 May 2025 16:08:59 GMT, Alan Bateman  wrote:

> Right, and another option to be to not introduce a new capability but it have it covered by SUPPORTS_OPENAT.

I thought of that but the code might be less clean. I will revisit the idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2922826064

From bpb at openjdk.org  Fri May 30 16:52:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 16:52:54 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
 
Message-ID: <7bvJf7BUYQLFFQ7H-u8t4DEcMwozVwjseZacxzj83PE=.1c3e298f-58d3-4b1b-9461-bd8f363fee3f@github.com>

On Fri, 30 May 2025 05:34:30 GMT, Alan Bateman  wrote:

> If you adds`int mode = UnixFileModeAttribute.toUnixMode(perms)` then it would avoid the repeated code and avoid the line splits, just makes it easier to read.

Agreed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25534#discussion_r2116255936

From alanb at openjdk.org  Fri May 30 17:26:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 17:26:51 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: 
References: 
 
 <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>
 
 
Message-ID: 

On Fri, 30 May 2025 16:20:12 GMT, Brian Burkhalter  wrote:

> I ran into this in testing:
> 
> ```
>     public long address() {
>         MemorySessionImpl session = session();
>         if (session != null) {
>             if (session.ownerThread() == null && session.isCloseable()) {
>                 throw new UnsupportedOperationException("ByteBuffer derived from closeable shared sessions not supported");
>             }
> ```
> 
> in `Direct-X-Buffer.java.template` when using the result of `Arena.ofShared`.

I previous comment wasn't comment, the above code where it checks isCloseable is correct. We should be able to use a buffer from a view allocated from the global arena or an automatic arena. It should throw UOE for confined and shared.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2922948922

From mullan at openjdk.org  Fri May 30 17:35:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 May 2025 17:35:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 30 May 2025 14:50:28 GMT, Michael McMahon  wrote:

>> src/java.base/share/conf/security/java.security line 1282:
>> 
>>> 1280: # Exception messages may include potentially sensitive information such as file
>>> 1281: # names, host names, or port numbers. By default, socket related exceptions
>>> 1282: # have this information restricted (meaning the sensitive details are removed).
>> 
>> I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.
>
> Fair point. I think we can make this clearer with a small addition. I propose to add the following sentence after the one starting "By default ..."
> 
> # Exception messages relating to Jar files and exceptions containing user
> # identity information are also restricted by default.

I would change "Jar" to "JAR" as I think that is the more common form and used in other places in this file. Looks fine otherwise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2116314192

From bpb at openjdk.org  Fri May 30 17:40:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 17:40:38 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat [v2]
In-Reply-To: 
References: 
Message-ID: <6K5o5-ABQQCO31rlbNowj5oVmZp2NkbixKBKAay57BU=.64694eb9-b2b1-477c-80f9-b0139887713c@github.com>

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

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

  8357425: Use int mode = UnixFileModeAttribute.toUnixMode(perms)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25534/files
  - new: https://git.openjdk.org/jdk/pull/25534/files/58cb7c9f..66de3e52

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

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

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

From bpb at openjdk.org  Fri May 30 17:40:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 17:40:38 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat [v2]
In-Reply-To: <7bvJf7BUYQLFFQ7H-u8t4DEcMwozVwjseZacxzj83PE=.1c3e298f-58d3-4b1b-9461-bd8f363fee3f@github.com>
References: 
 
 <7bvJf7BUYQLFFQ7H-u8t4DEcMwozVwjseZacxzj83PE=.1c3e298f-58d3-4b1b-9461-bd8f363fee3f@github.com>
Message-ID: 

On Fri, 30 May 2025 16:50:13 GMT, Brian Burkhalter  wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java line 423:
>> 
>>> 421:                 else if (fchmodatNoFollowSupported())
>>> 422:                     fchmodat(dfd, file, UnixFileModeAttribute.toUnixMode(perms),
>>> 423:                              AT_SYMLINK_NOFOLLOW);
>> 
>> The 4 cases look okay. If you adds`int mode = UnixFileModeAttribute.toUnixMode(perms)` then it would avoid the repeated code and avoid the line splits, just makes it easier to read.
>
>> If you adds`int mode = UnixFileModeAttribute.toUnixMode(perms)` then it would avoid the repeated code and avoid the line splits, just makes it easier to read.
> 
> Agreed.

So changed in https://github.com/openjdk/jdk/pull/25534/commits/66de3e524567deb8718b70c394c8877745de16fe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25534#discussion_r2116322355

From bpb at openjdk.org  Fri May 30 17:50:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 17:50:50 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: 
References: 
 
 <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>
 
 
 
Message-ID: 

On Fri, 30 May 2025 17:24:14 GMT, Alan Bateman  wrote:

> We should be able to use a buffer from a view allocated from the global arena or an automatic arena. It should throw UOE for confined and shared.

Currently `genBuffer` in `java/nio/channels/AsynchronousFileChannel/Basic.java` has this case:

            case 2 -> Arena.ofAuto().allocate(buf.length).asByteBuffer()
                    .put(buf)
                    .flip();

Other cases could be added there, e.g.,

            case 2 -> Arena.global().allocate(buf.length).asByteBuffer()
                    .put(buf)
                    .flip();

The UOE for confined and shared might have to be checked elsewhere. I'll examine it further.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2923021860

From bpb at openjdk.org  Fri May 30 18:10:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 18:10:09 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat [v3]
In-Reply-To: 
References: 
Message-ID: 

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

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

  8357425: Change view used to set directory permissions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25534/files
  - new: https://git.openjdk.org/jdk/pull/25534/files/66de3e52..bf2316ed

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

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

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

From bpb at openjdk.org  Fri May 30 18:10:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 18:10:09 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 30 May 2025 05:35:01 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357425: Change view used to set directory permissions
>
> src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java line 434:
> 
>> 432:                 }
>> 433:             } catch (UnixException x) {
>> 434:                 x.rethrowAsIOException(file);
> 
> 'file' will be null when changing the directory's permission, can you double check that case?

Verified.

Also updated the test in [bf2316e](https://github.com/openjdk/jdk/pull/25534/commits/bf2316ed8dbaa5215d564609417fca4b4f3363c8).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25534#discussion_r2116363744

From bpb at openjdk.org  Fri May 30 18:20:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 18:20:55 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 May 2025 08:13:53 GMT, Alan Bateman  wrote:

> I think it means that it is not supported on AIX because some of the "at" calls don't exist

The pertinent code in `UnixNativeDispatcher.c` is

    /* supports openat, etc. */
 
    if (my_openat_func != NULL &&  my_fstatat_func != NULL &&
        my_unlinkat_func != NULL && my_renameat_func != NULL &&
        my_fdopendir_func != NULL)
    {
        capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_OPENAT;
    }

Maybe the list of "at" syscalls needs to be reexamined and/or made more fine grained (not for this PR)?

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2923085384

From michaelm at openjdk.org  Fri May 30 20:50:37 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 20:50:37 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v17]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

  doc update to java.security

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/3eec6c03..5970c2b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=15-16

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

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

From michaelm at openjdk.org  Fri May 30 20:58:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 20:58:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v18]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:

 - doc update to java.security
 - removed jmod/Handler change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/5970c2b3..4aad0141

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=16-17

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

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

From bpb at openjdk.org  Fri May 30 21:31:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 21:31:57 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>
References: 
 
 <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>
Message-ID: 

On Fri, 30 May 2025 15:50:37 GMT, Brian Burkhalter  wrote:

>> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 452:
>> 
>>> 450:                 buf = dst;
>>> 451:                 address = ((DirectBuffer)dst).address() + pos;
>>> 452:                 IOUtil.acquireScope(dst, true);
>> 
>> I assume we'll have to change this to use IOUtil.bufferAddress(dst), and after the acquire.
>
> Noted.

I don't think that using `IOUtil.bufferAddress()` would be correct here. The reason is that it calls `JavaNioAccess.getBufferAddress()` which returns the value of `address` hoisted into `Buffer` thereby circumventing the check for closable shared sessions mentioned [below](https://github.com/openjdk/jdk/pull/25531#issuecomment-2922822498).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2116688743

From bpb at openjdk.org  Fri May 30 22:19:33 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 22:19:33 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers [v2]
In-Reply-To: 
References: 
Message-ID: 

> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

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

  8357847: Use IOUtil.bufferAddress; broaden testing of Arena types

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25531/files
  - new: https://git.openjdk.org/jdk/pull/25531/files/10000234..82fb9e0b

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

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

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

From bpb at openjdk.org  Fri May 30 22:30:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 22:30:51 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers
In-Reply-To: 
References: 
 
 <0Z1hOLAUkhLz4B9-QoBw4mZKXlbzvt-HrUpAMlccj80=.5faa80ce-587b-409d-801a-330806d7e7ec@github.com>
 
 
 
 
Message-ID: 

On Fri, 30 May 2025 17:47:48 GMT, Brian Burkhalter  wrote:

> We should be able to use a buffer from a view allocated from the global arena or an automatic arena. It should throw UOE for confined and shared.

It throws `IllegalStateException` for confined and UOE for shared. I have broadened testing in [82fb9e0](https://github.com/openjdk/jdk/pull/25531/commits/82fb9e0b896510d0b2b087519586e6eac3868a58).

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2923651889

From alanb at openjdk.org  Sat May 31 06:29:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 31 May 2025 06:29:50 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 30 May 2025 18:10:09 GMT, Brian Burkhalter  wrote:

>> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357425: Change view used to set directory permissions

Marked as reviewed by alanb (Reviewer).

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

> 185:         Set permsDir = getPosixFilePermissions(aDir);
> 186: 
> 187:         SecureDirectoryStream stream =

If you are doing any more edits then you can change this to use try-with-resources.

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

PR Review: https://git.openjdk.org/jdk/pull/25534#pullrequestreview-2883508197
PR Review Comment: https://git.openjdk.org/jdk/pull/25534#discussion_r2117389959

From alanb at openjdk.org  Sat May 31 06:38:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 31 May 2025 06:38:49 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 30 May 2025 18:18:01 GMT, Brian Burkhalter  wrote:

> Maybe the list of "at" syscalls needs to be reexamined and/or made more fine grained (not for this PR)?

Okay, let's go with what you have for now and we can mull over re-visiting this list. It dates from when the support for the "at" functions varied across operating systems and versions.

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2924500419

