From vyazici at openjdk.org  Mon Nov  3 10:09:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 10:09:29 GMT
Subject: RFR: 8366575: Remove SDP support
In-Reply-To: <H97VJmEKWaQtawOkZsPaxC98RvDtUkic7x2aAf3Di6w=.a0082c59-4b61-4dff-85cb-8795d31f66e1@github.com>
References: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
 <H97VJmEKWaQtawOkZsPaxC98RvDtUkic7x2aAf3Di6w=.a0082c59-4b61-4dff-85cb-8795d31f66e1@github.com>
Message-ID: <EoNfBEfjDYiQSbFrdqmHAyoCAiW1DL-zZBMBRiIaMA0=.a2ab4a61-c43d-4506-8ed7-a3e2a9096fee@github.com>

On Wed, 29 Oct 2025 17:23:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The only other mention of sdp I could find in the sources and test is in `ct.properties`

@dfuch, `ct.properties` is used by `javac -source 8`, and hence, should not be updated. Nevertheless, good that you raised this detail. I've created [JDK-8371133](https://bugs.openjdk.org/browse/JDK-8371133) to demystify it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28012#issuecomment-3479757650

From vyazici at openjdk.org  Tue Nov  4 08:06:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 08:06:47 GMT
Subject: Integrated: 8366575: Remove SDP support
In-Reply-To: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
References: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
Message-ID: <TM84-1r5XEo6kZjniboVj0jsAPzq0vL0vJcF6kX1sP0=.a2de2af9-0a09-4876-adee-51d75db28179@github.com>

On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Remove support for [SDP] (Sockets Direct Protocol), which has been obsolete for more than a decade ? see [JDK-8366575] for details. Tier1-2 is clear.
> 
> [SDP]: https://docs.oracle.com/javase/tutorial/sdp/sockets/overview.html
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

This pull request has now been integrated.

Changeset: c1476fca
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1476fca9d7a679d32b7b43956638b845d1027cc
Stats:     732 lines in 13 files changed: 0 ins; 732 del; 0 mod

8366575: Remove SDP support

Reviewed-by: alanb, erikj, jpai, michaelm

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

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

From bpb at openjdk.org  Wed Nov  5 01:01:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Nov 2025 01:01:12 GMT
Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for
 symbolic links in a mapped drive (win) [v2]
In-Reply-To: <FF548_dJBqnugMihCRQWlNtY5W_BHCSXmX4UqntgZ_c=.5082b69b-e9db-4c28-9603-14f551f09623@github.com>
References: <FF548_dJBqnugMihCRQWlNtY5W_BHCSXmX4UqntgZ_c=.5082b69b-e9db-4c28-9603-14f551f09623@github.com>
Message-ID: <ov8N2NhSY9KmqGse6Z02ZppmcTg_8f7Ybi_u8l9GVik=.9d4eef8a-30d9-4944-821c-76a2c7e7eea2@github.com>

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

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

  8368165: Improve fallback mechanism when a link cannot be opened for attribute access

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

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

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

  Stats: 51 lines in 1 file changed: 35 ins; 7 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28032/head:pull/28032

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

From bpb at openjdk.org  Wed Nov  5 02:03:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Nov 2025 02:03:54 GMT
Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for
 symbolic links in a mapped drive (win) [v2]
In-Reply-To: <ov8N2NhSY9KmqGse6Z02ZppmcTg_8f7Ybi_u8l9GVik=.9d4eef8a-30d9-4944-821c-76a2c7e7eea2@github.com>
References: <FF548_dJBqnugMihCRQWlNtY5W_BHCSXmX4UqntgZ_c=.5082b69b-e9db-4c28-9603-14f551f09623@github.com>
 <ov8N2NhSY9KmqGse6Z02ZppmcTg_8f7Ybi_u8l9GVik=.9d4eef8a-30d9-4944-821c-76a2c7e7eea2@github.com>
Message-ID: <sCEm8vNM3wG1lRqm1fqPnWWlrE_mkiCi7HbJWJ2K4Ic=.a080e2f1-0d0f-45dd-b607-a55434d6f943@github.com>

On Wed, 5 Nov 2025 01:01:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> If `getFinalPath` throws an exception, or converts a drive path to a UNC path, then fall back to the slow path which uses `resolveAllLinks`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8368165: Improve fallback mechanism when a link cannot be opened for attribute access

Commit 891561f, versus the mainline, changes getRealPath to fall back to resolveAllLinks if:

1. the reparse point encountered can be opened with the FILE_FLAG_OPEN_REPARSE_POINT flag set even though it could not be opened without this flag set; or
2. GetFinalPathNameByHandle converted a drive path to a UNC path.

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

PR Comment: https://git.openjdk.org/jdk/pull/28032#issuecomment-3488802095

From liach at openjdk.org  Wed Nov  5 23:34:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Nov 2025 23:34:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
Message-ID: <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>

On Fri, 24 Oct 2025 09:01:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework toString implementations

src/java.base/share/classes/java/lang/LazyConstant.java line 94:

> 92:  * lazy constant remains uninitialized.
> 93:  *
> 94:  * <h2 id="composition">Composing lazy constants</h2>

This section has some interesting usage, but I don't believe it should be included in the API specification. Behaviors described here can be derived from the formal specifications.

src/java.base/share/classes/java/lang/LazyConstant.java line 209:

> 207: 
> 208:     /**
> 209:      * {@return the contents of this lazy constant if initialized, otherwise,\

Suggestion:

     * {@return the contents of this lazy constant if initialized, otherwise,

src/java.base/share/classes/java/util/AbstractMap.java line 34:

> 32: 
> 33: import jdk.internal.vm.annotation.AOTSafeClassInitializer;
> 34: import jdk.internal.vm.annotation.Stable;

Suggestion:

src/java.base/share/classes/java/util/Currency.java line 146:

> 144:     private static ConcurrentMap<String, Currency> instances = new ConcurrentHashMap<>(7);
> 145:     private static final LazyConstant<HashSet<Currency>> available =
> 146:             LazyConstant.of(new Supplier<HashSet<Currency>>() {

Why can't we retain the method reference here? This is not used in early bootstrap.

src/java.base/share/classes/java/util/LazyCollections.java line 516:

> 514: 
> 515:         @ForceInline
> 516:         private void disposeOfMutex(long offset) {

I recommend removing this unused and otherwise confusing method.

src/java.base/share/classes/java/util/LazyCollections.java line 559:

> 557:     }
> 558: 
> 559:     public static <E> int lastIndexOf(List<LazyConstant<E>> list, Object o) {

This indexOf and lastIndexOf appear unused.

src/java.base/share/classes/java/util/Map.java line 1814:

> 1812:         final Set<K> keyCopies = Set.copyOf(keys);
> 1813:         Objects.requireNonNull(computingFunction);
> 1814:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {

I wonder if it's premature for us to optimize like this - for example, this would be wasteful if the key set contains one enum constant but there are 1000 enum constants in this enum.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496459406
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496468213
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496478562
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496479687
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496503928
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496514844
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496516750

From darcy at openjdk.org  Thu Nov  6 05:02:15 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Nov 2025 05:02:15 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
Message-ID: <LbYfgV9Gms8dQZG--UOFnysoefCwXEDuQLHUpkToeMo=.d2d02520-bce0-44e2-ab93-fc48ed669f02@github.com>

On Fri, 24 Oct 2025 09:01:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework toString implementations

src/java.base/share/classes/java/lang/LazyConstant.java line 184:

> 182:  *          Use in static initializers may interact with class initialization order;
> 183:  *          cyclic initialization may result in initialization errors as described
> 184:  *          in {@jls 12.4} of <cite>The Java Language Specification</cite>.

Please use some text like "section" or "&sect;" in from of the `@jls` tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2497396558

From bpb at openjdk.org  Fri Nov  7 21:37:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Nov 2025 21:37:34 GMT
Subject: RFR: 8371436: (fs) java/nio/file/FileStore/Basic.java fails on macOS
 platform due to assertTrue(!store.equals(prev));
Message-ID: <YmLM3EL3aJnurMuYcKDx4t2GlGzHUCWdnhSpnCIRHA8=.5654b726-ca52-4ebc-9103-3fa0b7a39d8a@github.com>

In `BsdNativeDispatcher.fsstatEntry()`, initialize the `UnixMountEntry` field `dev`, which propagates to `UnixFileStore` and is used in the latter's `equals` method, which `BsdFileStore` does not override.

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

Commit messages:
 - 8371436: (fs) java/nio/file/FileStore/Basic.java fails on macOS platform due to assertTrue(!store.equals(prev));

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

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

From bpb at openjdk.org  Fri Nov  7 21:37:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Nov 2025 21:37:34 GMT
Subject: RFR: 8371436: (fs) java/nio/file/FileStore/Basic.java fails on
 macOS platform due to assertTrue(!store.equals(prev));
In-Reply-To: <YmLM3EL3aJnurMuYcKDx4t2GlGzHUCWdnhSpnCIRHA8=.5654b726-ca52-4ebc-9103-3fa0b7a39d8a@github.com>
References: <YmLM3EL3aJnurMuYcKDx4t2GlGzHUCWdnhSpnCIRHA8=.5654b726-ca52-4ebc-9103-3fa0b7a39d8a@github.com>
Message-ID: <thsnBf_ItrEK5i-6DWmMn257NnjEpBtKpyoi6pj4Ztg=.34bcc5e1-f6d7-47b4-9cde-256148cbcf35@github.com>

On Fri, 7 Nov 2025 21:30:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `BsdNativeDispatcher.fsstatEntry()`, initialize the `UnixMountEntry` field `dev`, which propagates to `UnixFileStore` and is used in the latter's `equals` method, which `BsdFileStore` does not override.

It was found in testing on the node where the failure was observed, that the test `FileStore/Basic.java` continued to fail without this change, but succeeded with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28205#issuecomment-3505071718

From alanb at openjdk.org  Sat Nov  8 08:20:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 8 Nov 2025 08:20:01 GMT
Subject: RFR: 8371436: (fs) java/nio/file/FileStore/Basic.java fails on
 macOS platform due to assertTrue(!store.equals(prev));
In-Reply-To: <YmLM3EL3aJnurMuYcKDx4t2GlGzHUCWdnhSpnCIRHA8=.5654b726-ca52-4ebc-9103-3fa0b7a39d8a@github.com>
References: <YmLM3EL3aJnurMuYcKDx4t2GlGzHUCWdnhSpnCIRHA8=.5654b726-ca52-4ebc-9103-3fa0b7a39d8a@github.com>
Message-ID: <0tuy5qW6Cdduar42zBDaNRxTqnca6IvEe9BlAWBt88s=.879d1165-0d5a-4aea-b846-93e568226f7c@github.com>

On Fri, 7 Nov 2025 21:30:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `BsdNativeDispatcher.fsstatEntry()`, initialize the `UnixMountEntry` field `dev`, which propagates to `UnixFileStore` and is used in the latter's `equals` method, which `BsdFileStore` does not override.

So the dev field has always been 0, I assume this goes back to the original port to macOS in JDK 7u.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28205#pullrequestreview-3437782186

From pminborg at openjdk.org  Mon Nov 10 11:11:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 11:11:05 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v21]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <mW7TeaAZkRkmps0ITBT8LMdbEP7JPKL1lSixAc45KWQ=.7bdcb888-ae4b-428f-b286-bebb28078a8b@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits:

 - Merge master
 - Rework toString implementations
 - Update after doc comments
 - Merge branch 'master' into lazy-constants
 - Revert the AbstractMap.keySet @Stable annotation
 - Update docs after comments
 - Improve method docs
 - Improve equals/hashCode document
 - Update wording on List/Map Object methods
 - Update javadocs
 - ... and 97 more: https://git.openjdk.org/jdk/compare/681dab72...f775aaf1

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

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=20
  Stats: 8482 lines in 60 files changed: 3875 ins; 4490 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From pminborg at openjdk.org  Mon Nov 10 11:17:43 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 11:17:43 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v22]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <i7TM8ZzBjWYHIV28uZ2yCqPuRsYd-xeerIaSRpASFPI=.f9898317-3e6e-428e-ab18-c53d3e2f5059@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

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

  Fix merge mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/f775aaf1..003eaf1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=20-21

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

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

From pminborg at openjdk.org  Mon Nov 10 12:36:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 12:36:12 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
 <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>
Message-ID: <uAti75Ny7_zN9LInVXAewUujk3kcqIkzJuW_KqxbEro=.6652f9d9-2f8f-471d-83e0-69b90d5c9a51@github.com>

On Wed, 5 Nov 2025 23:31:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework toString implementations
>
> src/java.base/share/classes/java/util/Map.java line 1814:
> 
>> 1812:         final Set<K> keyCopies = Set.copyOf(keys);
>> 1813:         Objects.requireNonNull(computingFunction);
>> 1814:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {
> 
> I wonder if it's premature for us to optimize like this - for example, this would be wasteful if the key set contains one enum constant but there are 1000 enum constants in this enum.

There is a `min` and a `max` ordinal calculated, so in your example above, only one array item is used. I.e., if there are 1,000 enum constant and we are using enum with ordinal 42, then min = max = 42 and only a one-element array is ever allocated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2510377932

From pminborg at openjdk.org  Mon Nov 10 13:00:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 13:00:35 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v23]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <VdvBzwLN3yzDRSz3UYvaEJOKYaUtQVRVorlbDJc-dls=.81b0a2b8-3654-4cb0-bcd4-2f5649a222dc@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

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

  Address comments in PR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/003eaf1c..03616ef6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=21-22

  Stats: 119 lines in 6 files changed: 17 ins; 72 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From pminborg at openjdk.org  Mon Nov 10 14:59:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 14:59:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

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

  Add @AOTSafeClassInitializer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/03616ef6..e479cb4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=22-23

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

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

From bpb at openjdk.org  Mon Nov 10 15:46:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Nov 2025 15:46:58 GMT
Subject: RFR: 8371436: (fs) java/nio/file/FileStore/Basic.java fails on
 macOS platform due to assertTrue(!store.equals(prev));
In-Reply-To: <0tuy5qW6Cdduar42zBDaNRxTqnca6IvEe9BlAWBt88s=.879d1165-0d5a-4aea-b846-93e568226f7c@github.com>
References: <YmLM3EL3aJnurMuYcKDx4t2GlGzHUCWdnhSpnCIRHA8=.5654b726-ca52-4ebc-9103-3fa0b7a39d8a@github.com>
 <0tuy5qW6Cdduar42zBDaNRxTqnca6IvEe9BlAWBt88s=.879d1165-0d5a-4aea-b846-93e568226f7c@github.com>
Message-ID: <9IUHz_V6iHpywRWpNdseBECyrOgth0LSpE-uiaJSbv4=.c33fca93-34eb-48cc-98fe-f37eefc2c7f6@github.com>

On Sat, 8 Nov 2025 08:17:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So the dev field has always been 0, I assume this goes back to the original port to macOS in JDK 7u.

I would assume so. On Linux it looks to be set to `st_dev` via the attributes.

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

PR Comment: https://git.openjdk.org/jdk/pull/28205#issuecomment-3512499468

From pminborg at openjdk.org  Tue Nov 11 08:01:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 11 Nov 2025 08:01:08 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
Message-ID: <vqHNGKFE_YgCSlw0IFjWYKp7jxAEQGXAG8EkvjwyI78=.e505b8b6-ed21-4cb8-aa39-978db6cc0bef@github.com>

On Mon, 10 Nov 2025 14:59:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @AOTSafeClassInitializer

As per https://github.com/openjdk/jdk/pull/27605/commits/e479cb4bbe54f3e0caa129cc45aec2ec2bffd9cf, this PR passes tier 1-4 on multiple platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3515424778

From pminborg at openjdk.org  Wed Nov 12 10:07:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Nov 2025 10:07:39 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:

 - Clarify toString spec
 - Merge branch 'master' into lazy-constants
 - Add @AOTSafeClassInitializer
 - Address comments in PR
 - Fix merge mistake
 - Merge master
 - Rework toString implementations
 - Update after doc comments
 - Merge branch 'master' into lazy-constants
 - Revert the AbstractMap.keySet @Stable annotation
 - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

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

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=24
  Stats: 8445 lines in 60 files changed: 3836 ins; 4490 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From jvernee at openjdk.org  Wed Nov 12 16:39:57 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:57 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

Some initial comments on the spec and implementation. I still need to look at the tests.

src/java.base/share/classes/java/lang/LazyConstant.java line 48:

> 46:  * (provided at construction) will be invoked and the result will be used to initialize
> 47:  * the constant. Once a lazy constant is initialized, its contents can <em>never change</em>
> 48:  * and will be retrieved over and over again upon subsequent {@linkplain #get() get}

Are the above links to `#get()` also intended to have a the plain `get` text?

src/java.base/share/classes/java/lang/LazyConstant.java line 169:

> 167:  *          a lazy constant {@linkplain java.lang.ref##reachability strongly references}
> 168:  *          it contents. Hence, a lazy constant will hold its contents until
> 169:  *          the lazy constant itself is collected (if ever).

Maybe you could avoid the word 'collected' here, as there are no other references to the GC in this section, and no link to what GC is/does. i.e. I think 'collected' is not well-defined enough to be used here.

Suggestion:

 *          it contents. Hence, the contents of a lazy constant will be reachable as long
 *          as the lazy constant itself is reachable.

src/java.base/share/classes/java/lang/LazyConstant.java line 249:

> 247: 
> 248:     /**
> 249:      * {@return the {@linkplain System#identityHashCode(Object)} for this lazy constant}

How does this link render? It doesn't have any plain text. Maybe it's missing?

Suggestion:

     * {@return the {@linkplain System#identityHashCode(Object) identity hash code} for this lazy constant}

src/java.base/share/classes/java/lang/LazyConstant.java line 257:

> 255: 
> 256:     /**
> 257:      * {@return a non-initializing string suitable for debugging}

What is a 'non-initializing string'? ;) I think the second paragraph already covers this aspect, so you can leave it out here.

src/java.base/share/classes/java/lang/LazyConstant.java line 275:

> 273:     /**
> 274:      * {@return a lazy constant to be computed later via the provided
> 275:      *          {@code computingFunction}}

The function computes the contents, not the LC itself, so:

Suggestion:

     * {@return a lazy constant whose contents is to be computed later via the provided
     *          {@code computingFunction}}

src/java.base/share/classes/java/util/LazyCollections.java line 55:

> 53: 
> 54:     // Unsafe allows LazyCollection classes to be used early in the boot sequence
> 55:     static final Unsafe UNSAFE = Unsafe.getUnsafe();

Suggestion:

    private static final Unsafe UNSAFE = Unsafe.getUnsafe();

src/java.base/share/classes/java/util/LazyCollections.java line 66:

> 64:         // using `elements.length`.
> 65:         @Stable
> 66:         private final int size;

Is this really that important? What about the extra footprint added by the `int` field? We might have many instances of this class, but only one copy of the bytecode.

src/java.base/share/classes/java/util/LazyCollections.java line 199:

> 197:                 final int size = base.size();
> 198:                 subListRangeCheck(fromIndex, toIndex, size);
> 199:                 return new ReverseOrderLazyListView<>(base.subList(size - toIndex, size - fromIndex));

Why not this? (maybe add a comment?)
Suggestion:

                return new ReverseOrderLazyListView<>(base.subList(fromIndex, toIndex));

src/java.base/share/classes/java/util/LazyCollections.java line 264:

> 262: 
> 263:         @Stable
> 264:         private final Map<K, Integer> indexMapper;

This index mapper is a clever solution that avoids implementing a hashing function again. Lookups through this map can be folded because it is created using `Map.ofEntries`. I think you should put that in a comment here as well.

src/java.base/share/classes/java/util/LazyCollections.java line 433:

> 431:             @Override public V      getValue() {
> 432:                 final int index = map.indexFor(getKey);
> 433:                 final V v = map.getAcquire(getKey);

I suppose you could use `orElseCompute` here, since you already have the index

src/java.base/share/classes/java/util/LazyCollections.java line 488:

> 486:     static final class Mutexes {
> 487: 
> 488:         static final Object TOMB_STONE = new Object();

Suggestion:

        private static final Object TOMB_STONE = new Object();

src/java.base/share/classes/java/util/LazyCollections.java line 578:

> 576:             if (t == null) {
> 577:                 final T newValue = switch (functionHolder.function()) {
> 578:                     case Supplier<?> sup     -> (T) sup.get();

Is the held function ever a Supplier? I don't see a FunctionHolder being created with one.

src/java.base/share/classes/java/util/LazyCollections.java line 607:

> 605:         assert Thread.holdsLock(mutex) : index + "didn't hold " + mutex;
> 606:         // We know we hold the monitor here so plain semantic is enough
> 607:         if (array[index] == null) {

This should always be true when we get here, right?

src/java.base/share/classes/java/util/List.java line 1222:

> 1220:      * <p>
> 1221:      * Any {@link List#subList(int, int) subList()} or {@link List#reversed()} views
> 1222:      * of the returned list are also lazily computed.

Is this really about the views itself? Or about the elements? (AFAIK these views are typically lazily computed/created for others List impls as well)

Suggestion:

     * The elements of any {@link List#subList(int, int) subList()} or {@link List#reversed()} views
     * of the returned list are also lazily computed.

src/java.base/share/classes/java/util/Map.java line 1765:

> 1763:      * at most once per key, even in a multi-threaded environment. Competing
> 1764:      * threads accessing a value already under computation will block until an element
> 1765:      * is computed or an exception is thrown by the computing thread.

I think technically it's more correct to say something like '... or the computing function completes abnormally'. Since, if an exception is throw inside the computing function (by the computing thread), it may be caught and handled inside the computing function as well.

src/java.base/share/classes/java/util/Map.java line 1778:

> 1776:      * <p>
> 1777:      * Any {@link Map#values()} or {@link Map#entrySet()} views of the returned map are
> 1778:      * also lazily computed.

Suggestion:

     * The values of any {@link Map#values()} or {@link Map#entrySet()} views of the returned map are
     * also lazily computed.

src/java.base/share/classes/java/util/Map.java line 1817:

> 1815:         final Set<K> keyCopies = Set.copyOf(keys);
> 1816:         Objects.requireNonNull(computingFunction);
> 1817:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {

The fact that `keys` is being used here and not `keyCopies` looks a bit fishy. In general we should use the validated copy of our data in subsequent processing. Since `EnumSet` is mutable, it seems that these two could go out of sync.

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3448944313
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518699095
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518745565
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518765422
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518768972
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518779499
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518885149
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518897461
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518919343
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518968294
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518950708
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518970767
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519007486
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519002745
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518813240
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518832566
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518837814
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518880555

From jvernee at openjdk.org  Wed Nov 12 16:39:58 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:58 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <BPsL8gRBQYDTohQqPmBLVaEJ5NBxHEignbOmqf4YSVU=.30ee3776-265a-4966-860b-7f8ff7fc91a6@github.com>

On Wed, 12 Nov 2025 15:23:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 169:
> 
>> 167:  *          a lazy constant {@linkplain java.lang.ref##reachability strongly references}
>> 168:  *          it contents. Hence, a lazy constant will hold its contents until
>> 169:  *          the lazy constant itself is collected (if ever).
> 
> Maybe you could avoid the word 'collected' here, as there are no other references to the GC in this section, and no link to what GC is/does. i.e. I think 'collected' is not well-defined enough to be used here.
> 
> Suggestion:
> 
>  *          it contents. Hence, the contents of a lazy constant will be reachable as long
>  *          as the lazy constant itself is reachable.

Alternatively you could say something like 'becomes eligible for garbage collection', but I think defining the spec in terms of reachability is better, since that has a better definition in `java.lang.ref##reachability`.

> src/java.base/share/classes/java/util/Map.java line 1765:
> 
>> 1763:      * at most once per key, even in a multi-threaded environment. Competing
>> 1764:      * threads accessing a value already under computation will block until an element
>> 1765:      * is computed or an exception is thrown by the computing thread.
> 
> I think technically it's more correct to say something like '... or the computing function completes abnormally'. Since, if an exception is throw inside the computing function (by the computing thread), it may be caught and handled inside the computing function as well.

(Same for List)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518789003
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518834700

From jvernee at openjdk.org  Wed Nov 12 16:39:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:59 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
 <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>
 <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
Message-ID: <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>

On Mon, 13 Oct 2025 11:25:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Usually a null sentinel is used when null indicates something different. I think maybe to allow folding the empty case, we should probably add a new annotation or a new element-value to indicate this status and properly handle it in C1/C2 (similar to the field trusting in ciField)
>
> I've added two new benchmarks:
> 
> 
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42 = LazyConstant.of(() -> Optional.of(42));
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42_2 = LazyConstant.of(() -> Optional.of(42));
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY = LazyConstant.of(Optional::empty);
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY2 = LazyConstant.of(Optional::empty);
>     
>     ...
>     
>         @Benchmark
>     public int staticOptional42() {
>         return OPTIONAL_42.get().orElseThrow() + OPTIONAL_42_2.get().orElseThrow();
>     }
> 
>     @Benchmark
>     public boolean staticOptionalEmpty() {
>         return OPTIONAL_EMPTY.get().isEmpty() ^ OPTIONAL_EMPTY2.get().isEmpty();
>     }
> 
>     
> 
> 
> Which gives:
> 
> 
> Benchmark                              Mode  Cnt  Score   Error  Units
> StableValueBenchmark.staticOptional42  avgt   10  0.354 ? 0.045  ns/op
> 
> Benchmark                                 Mode  Cnt  Score   Error  Units
> StableValueBenchmark.staticOptionalEmpty  avgt   10  0.370 ? 0.030  ns/op
> 
> 
> So, both `Optional` variants appears to support constant folding.

I don't think we can drawn that conclusion just based on the speed. For the non-constant folded cases, this would be 2 loads and an xor.

I don't see how C2 would be allowed to constant fold the loads if the value is `null`, since that's explicitly forbidden by `@Stable` (and there's no easy way around that AFAIK, since the JIT thread may see a partially initialized object, so it conservatively ignores default values).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514951017

From jvernee at openjdk.org  Wed Nov 12 16:40:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:40:02 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
Message-ID: <fZvWSosJ0dpOekq5kMHya1CWSi5gEARpc_t-9KhX5qc=.203d607b-631d-46b3-a7fa-5def2552f15d@github.com>

On Mon, 10 Nov 2025 14:59:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @AOTSafeClassInitializer

src/java.base/share/classes/jdk/internal/lang/LazyConstantImpl.java line 47:

> 45: 
> 46:     // Unsafe allows `LazyConstant` instances to be used early in the boot sequence
> 47:     static final Unsafe UNSAFE = Unsafe.getUnsafe();

Suggestion:

    private static final Unsafe UNSAFE = Unsafe.getUnsafe();

test/jdk/java/lang/LazyConstant/LazyConstantSafePublicationTest.java line 117:

> 115:     @Test
> 116:     void mainTest() {
> 117:         CONSTANTS.set(constants());

Instead of passing this through a static field, why not just pass it through the constructor of Producer and Consumer? (which are created below)

test/micro/org/openjdk/bench/java/lang/stable/StableMapSingleBenchmark.java line 66:

> 64:     private static final Map<MyEnum, Integer> MAP_ENUM = Map.ofLazy(EnumSet.allOf(MyEnum.class), MyEnum::ordinal);
> 65:     private static final Map<MyEnum, Optional<Integer>> MAP_ENUM_OPTIONAL = Map.ofLazy(EnumSet.allOf(MyEnum.class), e -> Optional.of(e.ordinal()));
> 66:     private static final Function<Integer, Integer> FUNCTION = MAP::get;

I suppose the function variants are not very interesting to test, since they just delegate to Map::get, Maybe consider removing them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514957700
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514930623
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514913683

From duke at openjdk.org  Wed Nov 12 21:49:10 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 12 Nov 2025 21:49:10 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <ggdw6IJLb8vSl_FSPlfD6B-JOIQbaPXXetiZzK9r-SM=.e6340448-e798-4d81-a2d0-54e23a127f3c@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

src/java.base/share/classes/java/util/LazyCollections.java line 509:

> 507:                 return mutex;
> 508:             }
> 509:             // Protect against racy stores of mutexe candidates

Suggestion:

            // Protect against racy stores of mutex candidates

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518540555

From duke at openjdk.org  Wed Nov 12 21:49:12 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 12 Nov 2025 21:49:12 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <QOrBcIEhpsiMtBjYAIXYvE5gTFQDmQUUtNplF-uBTGU=.10d80411-1396-4e42-80d1-aa13749520f7@github.com>

On Wed, 12 Nov 2025 16:33:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 578:
> 
>> 576:             if (t == null) {
>> 577:                 final T newValue = switch (functionHolder.function()) {
>> 578:                     case Supplier<?> sup     -> (T) sup.get();
> 
> Is the held function ever a Supplier? I don't see a FunctionHolder being created with one.

This?is from?when `FunctionHolder` was?located in?the?`jdk.internal.lang.stable` package in?[GH?25878], and?was?used to?implement the?computing?function freeing?mechanism in?[`StableValue?::supplier(?)`].

[GH?25878]: https://github.com/openjdk/jdk/pull/25878
[`StableValue?::supplier(?)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/StableValue.html#supplier(java.util.function.Supplier)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519902578

From syan at openjdk.org  Thu Nov 13 04:03:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Nov 2025 04:03:42 GMT
Subject: RFR: 8371697: FileStore.getFileAttributeView("dos") should return null
 if unavailable
Message-ID: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>

Hi all,

I found that FileStore.supportsFileAttributeView("dos") return false, but Files.getFileAttributeView(file, viewClass) return none null, cause test/jdk/java/nio/file/FileStore/Basic.java fails on some linux-aarch64 machines.

This PR add check supportsFileAttributeView before return FileAttributeView in function getFileAttributeView.

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

Commit messages:
 - 8371697: FileStore.getFileAttributeView("dos") should return null if unavailable

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

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

From alanb at openjdk.org  Thu Nov 13 07:03:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 07:03:11 GMT
Subject: RFR: 8371697: FileStore.getFileAttributeView("dos") should return
 null if unavailable
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <XBn9rQTdr45oF0JhydsRCt2SFJnkybEDTICa9Ds2H3c=.f968d7f6-40d7-416a-b4e8-9b13d15811a5@github.com>

On Thu, 13 Nov 2025 03:54:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I found that FileStore.supportsFileAttributeView("dos") return false, but Files.getFileAttributeView(file, viewClass) return none null, cause test/jdk/java/nio/file/FileStore/Basic.java fails on some linux-aarch64 machines.
> 
> This PR add check supportsFileAttributeView before return FileAttributeView in function getFileAttributeView.

Files.getFileAttributeView returns a FileAttributeView if the file system provider supports it. I don't think we have an implementation bug here, instead I suspect there is a test issue here.

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

PR Comment: https://git.openjdk.org/jdk/pull/28281#issuecomment-3525872182

From bpb at openjdk.org  Thu Nov 13 19:02:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Nov 2025 19:02:28 GMT
Subject: Integrated: 8371436: (fs) java/nio/file/FileStore/Basic.java fails on
 macOS platform due to assertTrue(!store.equals(prev));
In-Reply-To: <YmLM3EL3aJnurMuYcKDx4t2GlGzHUCWdnhSpnCIRHA8=.5654b726-ca52-4ebc-9103-3fa0b7a39d8a@github.com>
References: <YmLM3EL3aJnurMuYcKDx4t2GlGzHUCWdnhSpnCIRHA8=.5654b726-ca52-4ebc-9103-3fa0b7a39d8a@github.com>
Message-ID: <iWzrA5pl0LICBrQJ6g43cXqqLm3P0CkJ15D4ygN8QaU=.1ebbf91f-3b47-4ae5-8990-fda373cc10be@github.com>

On Fri, 7 Nov 2025 21:30:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `BsdNativeDispatcher.fsstatEntry()`, initialize the `UnixMountEntry` field `dev`, which propagates to `UnixFileStore` and is used in the latter's `equals` method, which `BsdFileStore` does not override.

This pull request has now been integrated.

Changeset: db3a8386
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db3a8386d482c161c45fae1689826bd53709f11f
Stats:     11 lines in 1 file changed: 10 ins; 0 del; 1 mod

8371436: (fs) java/nio/file/FileStore/Basic.java fails on macOS platform due to assertTrue(!store.equals(prev));

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Thu Nov 13 19:04:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Nov 2025 19:04:39 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing
Message-ID: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>

In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.

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

Commit messages:
 - 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of sourcePosixView is confusing

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

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

From alanb at openjdk.org  Thu Nov 13 19:36:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 19:36:05 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing
In-Reply-To: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
Message-ID: <LMN9Ges_6ihFOHnPtOfRg5iZCIN4Qi_aaJPNZubuxrk=.581c797e-903f-4d88-ac48-3e337efb49b0@github.com>

On Thu, 13 Nov 2025 18:57:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.

src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 116:

> 114: 
> 115:         // retrieve whether source posix view is supported
> 116:         FileStore fileStore = provider.getFileStore(source);

I'm concerned this will add overhead to each copy operation. There shouldn't be any need to use FileStore in this method. If the provider supports the the POSIX view then this method can use it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28304#discussion_r2524691209

From alanb at openjdk.org  Thu Nov 13 19:36:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 19:36:05 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing
In-Reply-To: <LMN9Ges_6ihFOHnPtOfRg5iZCIN4Qi_aaJPNZubuxrk=.581c797e-903f-4d88-ac48-3e337efb49b0@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
 <LMN9Ges_6ihFOHnPtOfRg5iZCIN4Qi_aaJPNZubuxrk=.581c797e-903f-4d88-ac48-3e337efb49b0@github.com>
Message-ID: <rtyA64Zg4fvuxWTv1U2E8CBb-XDMZXM6xW-bj75NxsE=.9e702425-ebc4-4dd1-949e-00c5461e2405@github.com>

On Thu, 13 Nov 2025 19:32:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.
>
> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 116:
> 
>> 114: 
>> 115:         // retrieve whether source posix view is supported
>> 116:         FileStore fileStore = provider.getFileStore(source);
> 
> I'm concerned this will add overhead to each copy operation. There shouldn't be any need to use FileStore in this method. If the provider supports the the POSIX view then this method can use it.

So I think the summary is the JBS issue isn't really a bug, it's more than using sourcePosixView instead of boolean is confusing when looking at this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28304#discussion_r2524693092

From bpb at openjdk.org  Fri Nov 14 00:19:32 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Nov 2025 00:19:32 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing
In-Reply-To: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
Message-ID: <GoGekST4TjrDWQkIQw21MZKKSX-yYaG7hsRhz898pLU=.89a9f856-57ed-4763-864e-0ec94c82b979@github.com>

On Thu, 13 Nov 2025 18:57:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.

> There shouldn't be any need to use FileStore in this method.

Removed in commit bebf4a5.

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

PR Comment: https://git.openjdk.org/jdk/pull/28304#issuecomment-3530267681

From bpb at openjdk.org  Fri Nov 14 00:19:31 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Nov 2025 00:19:31 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v2]
In-Reply-To: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
Message-ID: <iCOBKdP7IYU2mTr9ozQY7mMJwh0ubAZ3CvNvQ6t6i-Y=.ac7eb55d-ab67-47ad-bca3-3bbf2b4685ed@github.com>

> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.

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

  8371689: Remove use of FileStore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28304/files
  - new: https://git.openjdk.org/jdk/pull/28304/files/fe0eedac..bebf4a5b

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

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

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

From syan at openjdk.org  Fri Nov 14 03:18:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 14 Nov 2025 03:18:07 GMT
Subject: RFR: 8371697: FileStore.getFileAttributeView("dos") should return
 null if unavailable
In-Reply-To: <XBn9rQTdr45oF0JhydsRCt2SFJnkybEDTICa9Ds2H3c=.f968d7f6-40d7-416a-b4e8-9b13d15811a5@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <XBn9rQTdr45oF0JhydsRCt2SFJnkybEDTICa9Ds2H3c=.f968d7f6-40d7-416a-b4e8-9b13d15811a5@github.com>
Message-ID: <0yNlZcGmiaED_FrH-kK8sG0-EiMbXjqSmlxPfiQGuvc=.02509e62-1844-456b-8559-62d4e2117161@github.com>

On Thu, 13 Nov 2025 07:00:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Files.getFileAttributeView returns a FileAttributeView if the file system provider supports it. I don't think we have an implementation bug here, instead I suspect there is a test issue here.

The[ java API doc](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/file/FileStore.html#getFileStoreAttributeView(java.lang.Class)) says getFileStoreAttributeView returns 'null if the attribute view is not available'. And the getFileStoreAttributeView function [comment](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/Files.java#L1638) also say getFileStoreAttributeView returns 'null if the attribute view is not available'.

If FileStore.supportsFileAttributeView(viewClass) and FileStore.supportsFileAttributeView(viewName) return false, does it means the attribute view is not available? If it does, I think the test do the right thing; If not, maybe we should fix this test.

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

PR Comment: https://git.openjdk.org/jdk/pull/28281#issuecomment-3530636872

From alanb at openjdk.org  Fri Nov 14 07:19:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 07:19:08 GMT
Subject: RFR: 8371697: FileStore.getFileAttributeView("dos") should return
 null if unavailable
In-Reply-To: <0yNlZcGmiaED_FrH-kK8sG0-EiMbXjqSmlxPfiQGuvc=.02509e62-1844-456b-8559-62d4e2117161@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <XBn9rQTdr45oF0JhydsRCt2SFJnkybEDTICa9Ds2H3c=.f968d7f6-40d7-416a-b4e8-9b13d15811a5@github.com>
 <0yNlZcGmiaED_FrH-kK8sG0-EiMbXjqSmlxPfiQGuvc=.02509e62-1844-456b-8559-62d4e2117161@github.com>
Message-ID: <7y1_cOg7aRqVs0i2iFvJZ0ZrwDFypxmKHkmLEQX_A2Y=.a76e92cf-8e6b-4cd1-b518-fe90eda2fa38@github.com>

On Fri, 14 Nov 2025 03:15:12 GMT, SendaoYan <syan at openjdk.org> wrote:

> If FileStore.supportsFileAttributeView(viewClass) and FileStore.supportsFileAttributeView(viewName) return false, does it means the attribute view is not available? If it does, I think the test do the right thing; If not, maybe we should fix this test.

A file system may be composed of many underlying file systems / volumes (modelled as FileStore in this API). A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores. 

>From the bug report then my guess is that this Linux file system doesn't have extended attributes enabled and this has tickled a bug in the test. In the test, I see the testFileAttributes method tests haveView == supported but this is not correct when the underlying FileStore doesn't support it. So I think we should rename the JBS issue to make it clear that it's a test failure, and fix the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/28281#issuecomment-3531242842

From mcimadamore at openjdk.org  Fri Nov 14 09:48:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 09:48:28 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

src/java.base/share/classes/java/lang/LazyConstant.java line 241:

> 239: 
> 240:     /**
> 241:      * {@return if this lazy constant is the same as the provided {@code obj}}

maybe add (either in this PR or as follow up) a clarification saying that two different lazy constant that point to the same contents are **not** equals

src/java.base/share/classes/java/lang/LazyConstant.java line 280:

> 278:      * {@code computingFunction} at least until initialization completes successfully.
> 279:      * <p>
> 280:      * If the provided computing function is already an instance of

Not sure how I feel about that -- it seems to soft-break equals...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526752889
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526762818

From mcimadamore at openjdk.org  Fri Nov 14 09:55:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 09:55:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <dlCmKBiCeip7juDtJLwy9oYLpsGRTUMVStcF9mDyLV8=.1ab12a3c-32e6-45d5-b02d-6766fae68287@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

Looks great -- just a couple more javadoc tweaks ;-)

src/java.base/share/classes/java/util/List.java line 1233:

> 1231:      * The returned list's {@linkplain Object#equals(Object) equals()} and
> 1232:      * {@linkplain Object#hashCode() hashCode()} methods may trigger initialization of one
> 1233:      * or more lazy elements. The returned list's {@linkplain Object#toString() toString()}

I thought we have concluded that all Object methods should behave as those in any other list, to maximize migration opportunities.

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3464050345
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526787780

From alanb at openjdk.org  Fri Nov 14 12:44:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 12:44:06 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v2]
In-Reply-To: <iCOBKdP7IYU2mTr9ozQY7mMJwh0ubAZ3CvNvQ6t6i-Y=.ac7eb55d-ab67-47ad-bca3-3bbf2b4685ed@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
 <iCOBKdP7IYU2mTr9ozQY7mMJwh0ubAZ3CvNvQ6t6i-Y=.ac7eb55d-ab67-47ad-bca3-3bbf2b4685ed@github.com>
Message-ID: <Xn0sa0vW40VMUIMQBeMGniTXzZxwa7q80Fxxld6tYDM=.d027e52a-75aa-4210-92e8-ba0b595f9f39@github.com>

On Fri, 14 Nov 2025 00:19:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371689: Remove use of FileStore

src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 114:

> 112:         // retrieve source posix view, null if unsupported
> 113:         final PosixFileAttributeView sourcePosixView =
> 114:             Files.getFileAttributeView(source, PosixFileAttributeView.class);

I don't think we should delete this. Instead, I think we can initialize sourceSupportsPosixAttributes with `Files.getFileAttributeView(source, PosixFileAttributeView.class) != null`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28304#discussion_r2527366691

From pminborg at openjdk.org  Fri Nov 14 13:35:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 13:35:17 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
 <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>
 <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
 <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>
Message-ID: <ScfYyTv6C7xkXpvHpTblrpnDZPVDn2LjYQHtjPjoevI=.ae9fbf73-afb3-48ff-87ee-c48ca1603ea1@github.com>

On Tue, 11 Nov 2025 16:48:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I've added two new benchmarks:
>> 
>> 
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42 = LazyConstant.of(() -> Optional.of(42));
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42_2 = LazyConstant.of(() -> Optional.of(42));
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY = LazyConstant.of(Optional::empty);
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY2 = LazyConstant.of(Optional::empty);
>>     
>>     ...
>>     
>>         @Benchmark
>>     public int staticOptional42() {
>>         return OPTIONAL_42.get().orElseThrow() + OPTIONAL_42_2.get().orElseThrow();
>>     }
>> 
>>     @Benchmark
>>     public boolean staticOptionalEmpty() {
>>         return OPTIONAL_EMPTY.get().isEmpty() ^ OPTIONAL_EMPTY2.get().isEmpty();
>>     }
>> 
>>     
>> 
>> 
>> Which gives:
>> 
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> StableValueBenchmark.staticOptional42  avgt   10  0.354 ? 0.045  ns/op
>> 
>> Benchmark                                 Mode  Cnt  Score   Error  Units
>> StableValueBenchmark.staticOptionalEmpty  avgt   10  0.370 ? 0.030  ns/op
>> 
>> 
>> So, both `Optional` variants appears to support constant folding.
>
> I don't think we can drawn that conclusion just based on the speed. For the non-constant folded cases, this would be 2 loads and an xor.
> 
> I don't see how C2 would be allowed to constant fold the loads if the value is `null`, since that's explicitly forbidden by `@Stable` (and there's no easy way around that AFAIK, since the JIT thread may see a partially initialized object, so it conservatively ignores default values).

Yes. I think you are right @JornVernee. I've explored several ways to fix this and the simplest one might be to have a sentinel value instead of `null` to flag emptiness. Splitting the class into a bimorphic implementation would not be good for `value` classes (at least not for now), even though the C2 might otherwise be able to optimize the two variants.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527523848

From pminborg at openjdk.org  Fri Nov 14 14:44:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 14:44:49 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <Wd007lKJSjzYhyuz3x2mNThGNk32iP9Mmh0ouOQc48Q=.98fb1ae5-ae22-458d-a2da-3ac3c4f7c2fe@github.com>

On Wed, 12 Nov 2025 16:02:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 66:
> 
>> 64:         // using `elements.length`.
>> 65:         @Stable
>> 66:         private final int size;
> 
> Is this really that important? What about the extra footprint added by the `int` field? We might have many instances of this class, but only one copy of the bytecode.

Hrrm. I wonder if the C2 compiler will end up producing equivalent code for the two variants? But there are merits to your argument.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527753354

From pminborg at openjdk.org  Fri Nov 14 15:15:51 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:15:51 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <7emI0lI9l1ZnKE89i3hDeQl4KiaE_GutmkDoIu772Ik=.276d7422-4102-425a-a92f-439134945f60@github.com>

On Wed, 12 Nov 2025 16:08:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 199:
> 
>> 197:                 final int size = base.size();
>> 198:                 subListRangeCheck(fromIndex, toIndex, size);
>> 199:                 return new ReverseOrderLazyListView<>(base.subList(size - toIndex, size - fromIndex));
> 
> Why not this? (maybe add a comment?)
> Suggestion:
> 
>                 return new ReverseOrderLazyListView<>(base.subList(fromIndex, toIndex));

Actually, now that toString() evaluates, we could just get rid of these classes and use the ones in the base class. Great!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527855543

From pminborg at openjdk.org  Fri Nov 14 15:35:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:35:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <sNjO1swdzNxW2L5GbPoiKqOMlTDoFlfr3SVhz3HHNgY=.4ee45512-ed3b-4ffb-bd00-580ea3844cf9@github.com>

On Wed, 12 Nov 2025 16:17:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 433:
> 
>> 431:             @Override public V      getValue() {
>> 432:                 final int index = map.indexFor(getKey);
>> 433:                 final V v = map.getAcquire(getKey);
> 
> I suppose you could use `orElseCompute` here, since you already have the index

Nice. Then we can get rid of the getAquire() method as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527915904

From pminborg at openjdk.org  Fri Nov 14 15:41:36 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:41:36 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <6zrll105lMejyo1PAG6cfBFzYt3N2-_9lIK6uP-Wl8A=.3e7908a7-71da-452e-8703-c4b7b5d661c3@github.com>

On Wed, 12 Nov 2025 16:32:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 607:
> 
>> 605:         assert Thread.holdsLock(mutex) : index + "didn't hold " + mutex;
>> 606:         // We know we hold the monitor here so plain semantic is enough
>> 607:         if (array[index] == null) {
> 
> This should always be true when we get here, right?

This is just an extra safety net to emulate a CAS op (while we are holding the monitor).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527936851

From bpb at openjdk.org  Fri Nov 14 17:25:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Nov 2025 17:25:34 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v3]
In-Reply-To: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
Message-ID: <GDdOaEbAHfZ0oO6DUfJy6GTvoUIVa-YcVt8H2i6mEjU=.7d82312d-fe7c-421b-a797-24c2ed9ac691@github.com>

> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.

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

  8371689: Determine posix attributes support based on the view being retrievable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28304/files
  - new: https://git.openjdk.org/jdk/pull/28304/files/bebf4a5b..ad290848

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

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

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

From bpb at openjdk.org  Fri Nov 14 17:25:36 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Nov 2025 17:25:36 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v3]
In-Reply-To: <Xn0sa0vW40VMUIMQBeMGniTXzZxwa7q80Fxxld6tYDM=.d027e52a-75aa-4210-92e8-ba0b595f9f39@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
 <iCOBKdP7IYU2mTr9ozQY7mMJwh0ubAZ3CvNvQ6t6i-Y=.ac7eb55d-ab67-47ad-bca3-3bbf2b4685ed@github.com>
 <Xn0sa0vW40VMUIMQBeMGniTXzZxwa7q80Fxxld6tYDM=.d027e52a-75aa-4210-92e8-ba0b595f9f39@github.com>
Message-ID: <tkhhNRZ28YlT8I_jEEzjRBm6PJiGOG1xgfXUbPQKTf0=.d5635cde-28f5-45d6-b58e-16fdbf34fb03@github.com>

On Fri, 14 Nov 2025 12:41:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't think we should delete this

So changed in ad29084.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28304#discussion_r2528319741

From alanb at openjdk.org  Fri Nov 14 18:11:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 18:11:05 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v3]
In-Reply-To: <GDdOaEbAHfZ0oO6DUfJy6GTvoUIVa-YcVt8H2i6mEjU=.7d82312d-fe7c-421b-a797-24c2ed9ac691@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
 <GDdOaEbAHfZ0oO6DUfJy6GTvoUIVa-YcVt8H2i6mEjU=.7d82312d-fe7c-421b-a797-24c2ed9ac691@github.com>
Message-ID: <9Je6jY9zCe8pntGTiqxJwdS8DebYY9glZ76Rz4uXB4o=.c59f23a2-389e-42f1-8af8-c0e25e9d08b9@github.com>

On Fri, 14 Nov 2025 17:25:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371689: Determine posix attributes support based on the view being retrievable

This update looks okay.

src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 122:

> 120:                                                PosixFileAttributes.class,
> 121:                                                linkOptions);
> 122:         if (sourceAttrs == null)

This could if-then-else too.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28304#pullrequestreview-3466137361
PR Review Comment: https://git.openjdk.org/jdk/pull/28304#discussion_r2528456180

From alanb at openjdk.org  Fri Nov 14 18:19:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 18:19:12 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v3]
In-Reply-To: <g7dm-c2ZGRKMktt8fxnR36hI86hhvdBatrCDTc0U580=.92cb8a40-c83b-4146-9bdc-9e86ee87348f@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
 <GDdOaEbAHfZ0oO6DUfJy6GTvoUIVa-YcVt8H2i6mEjU=.7d82312d-fe7c-421b-a797-24c2ed9ac691@github.com>
 <9Je6jY9zCe8pntGTiqxJwdS8DebYY9glZ76Rz4uXB4o=.c59f23a2-389e-42f1-8af8-c0e25e9d08b9@github.com>
 <g7dm-c2ZGRKMktt8fxnR36hI86hhvdBatrCDTc0U580=.92cb8a40-c83b-4146-9bdc-9e86ee87348f@github.com>
Message-ID: <m9Crf0ShZxkVKIrYq8n0jwWjnOi_5MxR0l-Nznob3wY=.dae2998b-98d8-406f-b51d-d9bfc5ccc361@github.com>

On Fri, 14 Nov 2025 18:11:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 122:
>> 
>>> 120:                                                PosixFileAttributes.class,
>>> 121:                                                linkOptions);
>>> 122:         if (sourceAttrs == null)
>> 
>> This could if-then-else too.
>
>> This could if-then-else too.
> 
> Since if the posix view is supported, then `sourceAttrs` could not be `null` here, correct?

Right, but it can be simplified to `if (sourceSupportsPosixAttributes) { .. } else { ..}`.  What you have is okay too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28304#discussion_r2528476157

From bpb at openjdk.org  Fri Nov 14 18:15:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Nov 2025 18:15:05 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v3]
In-Reply-To: <9Je6jY9zCe8pntGTiqxJwdS8DebYY9glZ76Rz4uXB4o=.c59f23a2-389e-42f1-8af8-c0e25e9d08b9@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
 <GDdOaEbAHfZ0oO6DUfJy6GTvoUIVa-YcVt8H2i6mEjU=.7d82312d-fe7c-421b-a797-24c2ed9ac691@github.com>
 <9Je6jY9zCe8pntGTiqxJwdS8DebYY9glZ76Rz4uXB4o=.c59f23a2-389e-42f1-8af8-c0e25e9d08b9@github.com>
Message-ID: <g7dm-c2ZGRKMktt8fxnR36hI86hhvdBatrCDTc0U580=.92cb8a40-c83b-4146-9bdc-9e86ee87348f@github.com>

On Fri, 14 Nov 2025 18:08:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This could if-then-else too.

Since if the posix view is supported, then `sourceAttrs` could not be `null` here, correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28304#discussion_r2528464825

From alanb at openjdk.org  Fri Nov 14 18:27:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 18:27:42 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v4]
In-Reply-To: <Pc68YjFKML1_dPx64IadKL8Kjs7oQfLFzK2Z0MT4Ns0=.897d1583-f16b-43c7-9463-ec8b173a7253@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
 <Pc68YjFKML1_dPx64IadKL8Kjs7oQfLFzK2Z0MT4Ns0=.897d1583-f16b-43c7-9463-ec8b173a7253@github.com>
Message-ID: <IO4gHnl64ZExHg7wMR8si9mdaw7bvdeQmouNrAZkhc8=.6870218e-d764-4867-aa99-8303ed3f2e0b@github.com>

On Fri, 14 Nov 2025 18:23:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371689: Simplify conditional

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28304#pullrequestreview-3466190239

From bpb at openjdk.org  Fri Nov 14 18:27:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Nov 2025 18:27:42 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v4]
In-Reply-To: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
Message-ID: <Pc68YjFKML1_dPx64IadKL8Kjs7oQfLFzK2Z0MT4Ns0=.897d1583-f16b-43c7-9463-ec8b173a7253@github.com>

> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.

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

  8371689: Simplify conditional

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28304/files
  - new: https://git.openjdk.org/jdk/pull/28304/files/ad290848..e76d2984

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

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

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

From bpb at openjdk.org  Fri Nov 14 18:27:44 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Nov 2025 18:27:44 GMT
Subject: RFR: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing [v3]
In-Reply-To: <m9Crf0ShZxkVKIrYq8n0jwWjnOi_5MxR0l-Nznob3wY=.dae2998b-98d8-406f-b51d-d9bfc5ccc361@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
 <GDdOaEbAHfZ0oO6DUfJy6GTvoUIVa-YcVt8H2i6mEjU=.7d82312d-fe7c-421b-a797-24c2ed9ac691@github.com>
 <9Je6jY9zCe8pntGTiqxJwdS8DebYY9glZ76Rz4uXB4o=.c59f23a2-389e-42f1-8af8-c0e25e9d08b9@github.com>
 <g7dm-c2ZGRKMktt8fxnR36hI86hhvdBatrCDTc0U580=.92cb8a40-c83b-4146-9bdc-9e86ee87348f@github.com>
 <m9Crf0ShZxkVKIrYq8n0jwWjnOi_5MxR0l-Nznob3wY=.dae2998b-98d8-406f-b51d-d9bfc5ccc361@github.com>
Message-ID: <hyJ1NBP6TC8mPEN6F0NUJ2X_bM5zH_pr1x3pvyCEXCQ=.040c8d54-b681-4beb-9aee-3dec83d2527b@github.com>

On Fri, 14 Nov 2025 18:15:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  it can be simplified

So changed in e76d298.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28304#discussion_r2528488481

From syan at openjdk.org  Sat Nov 15 02:36:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 15 Nov 2025 02:36:36 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v2]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <DrkohrGvO6jkgyiXuH67XcbvaY64UQOka9jjFcSU4jQ=.25d08460-26bb-43b5-9343-1cfdf4b83064@github.com>

> Hi all,
> 
> I found that FileStore.supportsFileAttributeView("dos") return false, but Files.getFileAttributeView(file, viewClass) return none null, cause test/jdk/java/nio/file/FileStore/Basic.java fails on some linux-aarch64 machines.
> 
> This PR add check supportsFileAttributeView before return FileAttributeView in function getFileAttributeView.

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

 - Check "haveView == supported" only on AIX
 - Revert "8371697: FileStore.getFileAttributeView("dos") should return null if unavailable"
   
   This reverts commit f83b081532b800226bdc92259154f36839991767.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/f83b0815..e11bc85d

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

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

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

From syan at openjdk.org  Sat Nov 15 02:43:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 15 Nov 2025 02:43:38 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v3]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <7jrzbqgpVg_viZe6HOVLGgnnyFvfsRtgSvNdD45FF-Y=.0ad4c9dc-5156-4239-addc-06fcee906774@github.com>

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores. So I think the new added check `haveView == supported` is too strict on non-AIX systems. This PR make this check only on AIX.
> 
> Change has been verified locally on linux-aarch64.

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

  Add whithesapce after if

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/e11bc85d..9be87fa3

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

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

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

From syan at openjdk.org  Sat Nov 15 02:43:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 15 Nov 2025 02:43:39 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux
In-Reply-To: <7y1_cOg7aRqVs0i2iFvJZ0ZrwDFypxmKHkmLEQX_A2Y=.a76e92cf-8e6b-4cd1-b518-fe90eda2fa38@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <XBn9rQTdr45oF0JhydsRCt2SFJnkybEDTICa9Ds2H3c=.f968d7f6-40d7-416a-b4e8-9b13d15811a5@github.com>
 <0yNlZcGmiaED_FrH-kK8sG0-EiMbXjqSmlxPfiQGuvc=.02509e62-1844-456b-8559-62d4e2117161@github.com>
 <7y1_cOg7aRqVs0i2iFvJZ0ZrwDFypxmKHkmLEQX_A2Y=.a76e92cf-8e6b-4cd1-b518-fe90eda2fa38@github.com>
Message-ID: <p3vLFtdDx5x5OXXm9xiBV_292FEXdN2T7pjIPiaA3ek=.61e1ad57-363e-4d44-90e1-9665fae8413f@github.com>

On Fri, 14 Nov 2025 07:16:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  So I think we should rename the JBS issue to make it clear that it's a test failure, and fix the test.

The PR subject and description has been updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/28281#issuecomment-3535439567

From alanb at openjdk.org  Sat Nov 15 09:09:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Nov 2025 09:09:36 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v3]
In-Reply-To: <7jrzbqgpVg_viZe6HOVLGgnnyFvfsRtgSvNdD45FF-Y=.0ad4c9dc-5156-4239-addc-06fcee906774@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <7jrzbqgpVg_viZe6HOVLGgnnyFvfsRtgSvNdD45FF-Y=.0ad4c9dc-5156-4239-addc-06fcee906774@github.com>
Message-ID: <9WM0YeatEtZpGYK6lgN5tUmyWg7oqt-GX-yGnf04ZFY=.310ec03e-5200-4671-88c1-c1404066c4cb@github.com>

On Sat, 15 Nov 2025 02:43:38 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores. So I think the new added check `haveView == supported` is too strict on non-AIX systems. This PR make this check only on AIX.
>> 
>> Change has been verified locally on linux-aarch64.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add whithesapce after if

test/jdk/java/nio/file/FileStore/Basic.java line 82:

> 80:             boolean haveView = Files.getFileAttributeView(file, viewClass) != null;
> 81:             assertTrue(haveView == supported);
> 82:         }

I think we should replace L76-L77 with

if (supported) {
    assertNotNull(Files.getFileAttributeView(file, viewClass));
}

so no need for anything AIX specific here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28281#discussion_r2529718468

From pminborg at openjdk.org  Sun Nov 16 09:40:19 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Sun, 16 Nov 2025 09:40:19 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>
Message-ID: <CQ7EtP0euKkv6mqVzXXTc40PyYxMwy_WPzuw9zf_K0A=.5abfa43c-df2f-4201-a196-7c533514bda8@github.com>

On Fri, 14 Nov 2025 09:45:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 280:
> 
>> 278:      * {@code computingFunction} at least until initialization completes successfully.
>> 279:      * <p>
>> 280:      * If the provided computing function is already an instance of
> 
> Not sure how I feel about that -- it seems to soft-break equals...

Let's think about this once more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2531779955

From syan at openjdk.org  Mon Nov 17 02:20:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 02:20:50 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v4]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <7mzvUsMjJue7sdkL3oapnuHQB7DJA2zciz29PXmnP8s=.0641ac36-b81a-456e-a4df-01a5eeaf6ca4@github.com>

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores. So I think the new added check `haveView == supported` is too strict on non-AIX systems. This PR make this check only on AIX.
> 
> Change has been verified locally on linux-aarch64.

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

  Replace assertNotNull for "Files.getFileAttributeView(file, viewClass)" when supported is true

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/9be87fa3..96223e5a

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

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

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

From syan at openjdk.org  Mon Nov 17 02:28:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 02:28:49 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v5]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <HHcBzpKvtIGITB_WjFnG2d1oY9CfHg3-D0S4CYcr9qU=.05e0a67d-9382-45cb-9df4-ca3239cb8199@github.com>

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores. So I think the new added check `haveView == supported` is too strict on non-AIX systems. This PR make this check only on AIX.
> 
> Change has been verified locally on linux-aarch64.

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

  import jdk.test.lib.Asserts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/96223e5a..89a02a12

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

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

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

From syan at openjdk.org  Mon Nov 17 02:36:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 02:36:43 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v6]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <GdlvhzQBug75mft6vm72vB0fJJLulvYyzssG6UuB3VE=.915abc72-fa1f-424c-b4ae-933e402f810d@github.com>

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
> 
> Change has been verified locally on linux-aarch64.

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

  Add the comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/89a02a12..c97ec541

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

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

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

From syan at openjdk.org  Mon Nov 17 02:36:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 02:36:44 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v3]
In-Reply-To: <9WM0YeatEtZpGYK6lgN5tUmyWg7oqt-GX-yGnf04ZFY=.310ec03e-5200-4671-88c1-c1404066c4cb@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <7jrzbqgpVg_viZe6HOVLGgnnyFvfsRtgSvNdD45FF-Y=.0ad4c9dc-5156-4239-addc-06fcee906774@github.com>
 <9WM0YeatEtZpGYK6lgN5tUmyWg7oqt-GX-yGnf04ZFY=.310ec03e-5200-4671-88c1-c1404066c4cb@github.com>
Message-ID: <yEDiuPX6t22dpWnZywH8gLN445EhKlKYL2LlDvTv56c=.60233828-2f90-4251-9c5b-b30bea69084a@github.com>

On Sat, 15 Nov 2025 09:06:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add whithesapce after if
>
> test/jdk/java/nio/file/FileStore/Basic.java line 82:
> 
>> 80:             boolean haveView = Files.getFileAttributeView(file, viewClass) != null;
>> 81:             assertTrue(haveView == supported);
>> 82:         }
> 
> I think we should replace L76-L77 with
> 
> if (supported) {
>     assertNotNull(Files.getFileAttributeView(file, viewClass));
> }
> 
> so no need for anything AIX specific here.

Thanks for the suggestion. updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28281#discussion_r2532476225

From alanb at openjdk.org  Mon Nov 17 06:56:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 06:56:03 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v6]
In-Reply-To: <GdlvhzQBug75mft6vm72vB0fJJLulvYyzssG6UuB3VE=.915abc72-fa1f-424c-b4ae-933e402f810d@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <GdlvhzQBug75mft6vm72vB0fJJLulvYyzssG6UuB3VE=.915abc72-fa1f-424c-b4ae-933e402f810d@github.com>
Message-ID: <dEJN7Tc_Q5EuzGoKGdTJyGHoc5Uh7KkPRV5vkW62oRE=.893b22ed-c4b7-4979-a453-53bbba809c2c@github.com>

On Mon, 17 Nov 2025 02:36:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
>> 
>> Change has been verified locally on linux-aarch64.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the comment

test/jdk/java/nio/file/FileStore/Basic.java line 41:

> 39: import jdk.test.lib.Platform;
> 40: import jdk.test.lib.util.FileUtils;
> 41: import jdk.test.lib.Asserts;

If this test is now using jdk.test.lib.Asserts then we should the assertTrue method, and create an issue to remind us to move this to JUnit.

test/jdk/java/nio/file/FileStore/Basic.java line 80:

> 78:         // in these views may not supported on all FileStores.
> 79:         // So we only check for non-null view if the store supports the view.
> 80:         if (supported) {

I would prefer if the comment said something like "If the view is supported by the FileStore then Files.getFileAttributeView should return return that view".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28281#discussion_r2532907241
PR Review Comment: https://git.openjdk.org/jdk/pull/28281#discussion_r2532911416

From syan at openjdk.org  Mon Nov 17 07:12:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 07:12:26 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v7]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <wLf-uW0BCeWMdU05dW7jLXUryn4So5wVMLJ4pQqDKoY=.7bc47838-d9a8-4160-92f7-5f0ce33b317d@github.com>

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
> 
> Change has been verified locally on linux-aarch64.

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

 - Update the comment
 - Update the comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/c97ec541..270c85e9

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

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

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

From syan at openjdk.org  Mon Nov 17 07:12:28 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 07:12:28 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v6]
In-Reply-To: <dEJN7Tc_Q5EuzGoKGdTJyGHoc5Uh7KkPRV5vkW62oRE=.893b22ed-c4b7-4979-a453-53bbba809c2c@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <GdlvhzQBug75mft6vm72vB0fJJLulvYyzssG6UuB3VE=.915abc72-fa1f-424c-b4ae-933e402f810d@github.com>
 <dEJN7Tc_Q5EuzGoKGdTJyGHoc5Uh7KkPRV5vkW62oRE=.893b22ed-c4b7-4979-a453-53bbba809c2c@github.com>
Message-ID: <ZUieUYaXT8i5re2TAjzgOk3qvDywwrSPBmtkYXaoyMY=.679188bf-80b2-468a-bd04-4d76aa4920f8@github.com>

On Mon, 17 Nov 2025 06:53:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add the comment
>
> test/jdk/java/nio/file/FileStore/Basic.java line 80:
> 
>> 78:         // in these views may not supported on all FileStores.
>> 79:         // So we only check for non-null view if the store supports the view.
>> 80:         if (supported) {
> 
> I would prefer if the comment said something like "If the view is supported by the FileStore then Files.getFileAttributeView should return return that view".

Thanks, the comment has been updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28281#discussion_r2532943332

From syan at openjdk.org  Mon Nov 17 07:21:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 07:21:43 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v8]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <Xrft6f7K537j8P6bUH9e_Y8Os0yZSBUW5sCBcKhX3wA=.193233e0-e923-43ae-a9fc-a0a876b162c6@github.com>

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
> 
> Change has been verified locally on linux-aarch64.

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

  Use Asserts.assertTrue instead of Asserts.assertNotNull

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/270c85e9..6e13bcbe

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

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

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

From syan at openjdk.org  Mon Nov 17 07:29:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 07:29:04 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v6]
In-Reply-To: <dEJN7Tc_Q5EuzGoKGdTJyGHoc5Uh7KkPRV5vkW62oRE=.893b22ed-c4b7-4979-a453-53bbba809c2c@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <GdlvhzQBug75mft6vm72vB0fJJLulvYyzssG6UuB3VE=.915abc72-fa1f-424c-b4ae-933e402f810d@github.com>
 <dEJN7Tc_Q5EuzGoKGdTJyGHoc5Uh7KkPRV5vkW62oRE=.893b22ed-c4b7-4979-a453-53bbba809c2c@github.com>
Message-ID: <qWOKNmBRSqaPEoHfFeyzLampxa6wYzDzIvIyQO37MHg=.c3c50536-13cf-41e6-8130-3ca5fca4eee9@github.com>

On Mon, 17 Nov 2025 06:51:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add the comment
>
> test/jdk/java/nio/file/FileStore/Basic.java line 41:
> 
>> 39: import jdk.test.lib.Platform;
>> 40: import jdk.test.lib.util.FileUtils;
>> 41: import jdk.test.lib.Asserts;
> 
> If this test is now using jdk.test.lib.Asserts then we should the assertTrue method, and create an issue to remind us to move this to JUnit.

Asserts.assertNotNull has been replaced as Asserts.assertTrue.

And the [issue](https://bugs.openjdk.org/browse/JDK-8371979) has been created.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28281#discussion_r2532984178

From syan at openjdk.org  Mon Nov 17 07:36:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 07:36:56 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v9]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <Nn6Ji9bB2HFhICJpMn2_aBzxQiDf4IqUn4B_b6QgTNc=.5df2981e-ee54-483a-8527-dfd424eda5a1@github.com>

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
> 
> Change has been verified locally on linux-aarch64.

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

  Use assertTrue instead of Assert.assertTrue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/6e13bcbe..bab6b938

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

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

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

From alanb at openjdk.org  Mon Nov 17 07:36:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 07:36:58 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v8]
In-Reply-To: <Xrft6f7K537j8P6bUH9e_Y8Os0yZSBUW5sCBcKhX3wA=.193233e0-e923-43ae-a9fc-a0a876b162c6@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <Xrft6f7K537j8P6bUH9e_Y8Os0yZSBUW5sCBcKhX3wA=.193233e0-e923-43ae-a9fc-a0a876b162c6@github.com>
Message-ID: <7vXsQCjHAtxfmqomuRLtvn158J7Sw-d56ERKG3DLrho=.9447009a-873c-4938-8028-38c043c3523d@github.com>

On Mon, 17 Nov 2025 07:21:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
>> 
>> Change has been verified locally on linux-aarch64.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Asserts.assertTrue instead of Asserts.assertNotNull

I should have been clearer in my comments. If this test is changed to jdk.test.lib.Asserts then I think we should remove the local assertTrue method. The simplest is to just `import static jdk.test.lib.Asserts.*` and remove the local assertTrue method, it should just work.  The assertNotNull in the previous iteration was good, and better than assertTrue as you get a better diagnostic in the event of a failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/28281#issuecomment-3540336641

From syan at openjdk.org  Mon Nov 17 07:52:17 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 07:52:17 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v10]
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <-zfO0iSXmChD9ZXFyz5A0hV1Xvh94DgJ-Kj5T5pzbHU=.0711d3c0-7b45-4c14-b4ea-5aa3ecbf7b06@github.com>

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
> 
> Change has been verified locally on linux-aarch64.

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

  Use assertNotNull instead of assertTrue, and remove the local assertTrue method implementation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28281/files
  - new: https://git.openjdk.org/jdk/pull/28281/files/bab6b938..067191cb

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

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

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

From syan at openjdk.org  Mon Nov 17 07:52:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 07:52:19 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v8]
In-Reply-To: <7vXsQCjHAtxfmqomuRLtvn158J7Sw-d56ERKG3DLrho=.9447009a-873c-4938-8028-38c043c3523d@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <Xrft6f7K537j8P6bUH9e_Y8Os0yZSBUW5sCBcKhX3wA=.193233e0-e923-43ae-a9fc-a0a876b162c6@github.com>
 <7vXsQCjHAtxfmqomuRLtvn158J7Sw-d56ERKG3DLrho=.9447009a-873c-4938-8028-38c043c3523d@github.com>
Message-ID: <sgrXw7uNWF_byYgTJLQn1StJ4SoI4N7W6VUnx02jgFs=.7bce9911-46a8-40e8-a084-450fdfa9b970@github.com>

On Mon, 17 Nov 2025 07:30:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> import static jdk.test.lib.Asserts.*

Sorry for the misunderstood.

The assertTrue has been replaced as assertNotNull. and the local assertTrue local implementation has been removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28281#issuecomment-3540397524

From alanb at openjdk.org  Mon Nov 17 08:56:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 08:56:14 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v10]
In-Reply-To: <-zfO0iSXmChD9ZXFyz5A0hV1Xvh94DgJ-Kj5T5pzbHU=.0711d3c0-7b45-4c14-b4ea-5aa3ecbf7b06@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <-zfO0iSXmChD9ZXFyz5A0hV1Xvh94DgJ-Kj5T5pzbHU=.0711d3c0-7b45-4c14-b4ea-5aa3ecbf7b06@github.com>
Message-ID: <8hmtt1cR95Lng47JjQsBwmGoUPMtnmNS5Iq-mYMc3I4=.6551a868-b138-4db5-90c3-b0902ffda4ce@github.com>

On Mon, 17 Nov 2025 07:52:17 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
>> 
>> Change has been verified locally on linux-aarch64.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use assertNotNull instead of assertTrue, and remove the local assertTrue method implementation

Thanks for taking the feedback, latest version looks good.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28281#pullrequestreview-3471634144

From pminborg at openjdk.org  Mon Nov 17 09:32:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 09:32:02 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v26]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits:

 - Merge branch 'master' into lazy-constants
 - Merge master
 - Fix tests and improve docs
 - Remove inner classes in LazyList
 - Fix TOC TOU issue
 - Improve documentation for List and Map factories
 - Improve doc details
 - Improve text for hashCode()
 - Refine text about reachabilit of the contents
 - Align doc links for get()
 - ... and 115 more: https://git.openjdk.org/jdk/compare/69e30244...3c26e095

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

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=25
  Stats: 8347 lines in 60 files changed: 3738 ins; 4490 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From mcimadamore at openjdk.org  Mon Nov 17 11:19:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 17 Nov 2025 11:19:15 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v26]
In-Reply-To: <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>
Message-ID: <UsVyM2P1jaGf874UM25dFDMfBQWBlhOyN22wwSfWqtQ=.04e2a58d-9a6d-4cf7-a274-df3f1645c64e@github.com>

On Mon, 17 Nov 2025 09:32:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits:
> 
>  - Merge branch 'master' into lazy-constants
>  - Merge master
>  - Fix tests and improve docs
>  - Remove inner classes in LazyList
>  - Fix TOC TOU issue
>  - Improve documentation for List and Map factories
>  - Improve doc details
>  - Improve text for hashCode()
>  - Refine text about reachabilit of the contents
>  - Align doc links for get()
>  - ... and 115 more: https://git.openjdk.org/jdk/compare/69e30244...3c26e095

src/java.base/share/classes/java/lang/LazyConstant.java line 244:

> 242:      * <p>
> 243:      * In other words, equals compares the identity of this lazy constant and {@code obj}
> 244:      * to determine equality. Hence, two lazy constant with the same contents are

Suggestion:

     * to determine equality. Hence, two lazy constants with the same contents are

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533674027

From pminborg at openjdk.org  Mon Nov 17 11:29:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 11:29:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v27]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <wmiyzAjTgb4hBR9rFi5881eXvQIwzbbKNdYHSxj_VQI=.16face2a-40c5-4d1d-bd31-335b6b020d33@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

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

  Fix forgotten text about (List|Map)::toString

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/3c26e095..2d8f98fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=25-26

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

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

From mcimadamore at openjdk.org  Mon Nov 17 11:38:04 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 17 Nov 2025 11:38:04 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <iq1Jk7NLAvqBhVwcS95kaY0cgFCRt1DKCg_FfVZZSYY=.730253ad-fb3c-4546-ba66-8a0a7924fda7@github.com>

On Mon, 17 Nov 2025 11:34:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Great work!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3472270393

From pminborg at openjdk.org  Mon Nov 17 11:38:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 11:38:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/2d8f98fe..e5399c5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=26-27

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

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

From duke at openjdk.org  Mon Nov 17 13:26:20 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 17 Nov 2025 13:26:20 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

I've had a look mostly at the docs, everything I'm saying is optional (though I'd really like to see the Logger example changed).

src/java.base/share/classes/java/lang/LazyConstant.java line 42:

> 40:  * A lazy constant is created using the factory method
> 41:  * {@linkplain LazyConstant#of(Supplier) LazyConstant.of({@code <computing function>})}.
> 42:  * When created, the lazy constant is <em>not initialized</em>, meaning it has no contents.

Subjectively, might this be clearer as a bulleted list? This is a sequence of statements about the state transitions after all.

<ul>
<li>On creation the lazy constant is <em>not initialized</em> ...
<li>The first time {@linkplain #get() get()} is called ...
<li>Once a lazy constant is initialized ...

Or just splitting by paragraph.

src/java.base/share/classes/java/lang/LazyConstant.java line 60:

> 58:  *    private final LazyConstant<Logger> logger =
> 59:  *            // @link substring="of" target="#of" :
> 60:  *            LazyConstant.of( () -> Logger.create(Component.class) );

We had previously talked about whether the `Logger` example is a good one.

Personally I think it's a bad example if it encourages people to use loggers this way since:
* non static loggers aren't suitable to logging in static methods.
* The Logger framework has a perfectly functional mechanism for injecting static logger instances.
* Over-use of non-static logger instances pollutes internal APIs and ends up leaking a dependency on a specific logger instance, making refactoring hard.

src/java.base/share/classes/java/lang/LazyConstant.java line 66:

> 64:  *        // ...
> 65:  *    }
> 66:  * }

Arguably weird/wrong indents on closing '}' ?

src/java.base/share/classes/java/lang/LazyConstant.java line 241:

> 239: 
> 240:     /**
> 241:      * {@return if this lazy constant is the same as the provided {@code obj}}

Maybe say "is the same instance as ...", then you might be able to shorten the "In other words" paragraph below as they sort of say the same thing in almost the same words.

As a reader I'm more interested in *why* this slightly unexpected behaviour happens. Maybe a section in the class level docs, linked from here, explaining the issues with using the content for equals/hashCode would be better (that can also talk about lazy constants being mostly unsuitable as key types).

src/java.base/share/classes/java/lang/LazyConstant.java line 283:

> 281:      * <p>
> 282:      * The returned lazy constant strongly references the provided
> 283:      * {@code computingFunction} at least until initialization completes successfully.

As a reader I'm a bit nervous that I don't know if it will ever drop the function. Suppose my init relies on something chunky I want to be sure has gone away?

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

> 1: /*

Side note: I'm slightly surprised to see the introduction and the usage happening in the same PR. Is this really being submitting in one go?

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

> 617: 
> 618:     private static final LazyConstant<Charset> defaultCharset = LazyConstant.of(
> 619:             new Supplier<>() { public Charset get() { return defaultCharset0(); }});

Can these not be done with lambdas?

src/java.base/share/classes/java/util/List.java line 1210:

> 1208:      * invoked at most once per list index, even in a multi-threaded environment.
> 1209:      * Competing threads accessing an element already under computation will block until
> 1210:      * an element is computed or the computing function completes abnormally

Missing full-stop.

src/java.base/share/classes/java/util/List.java line 1238:

> 1236:      * <p>
> 1237:      * The returned lazy list strongly references its computing
> 1238:      * function used to compute elements at least so long as there are uninitialized

"at least so long as" sounds weird to me.

I think you would say either:
* "... at least *as* long as there are uninitialized elmements."
* "... so long as there are uninitialized elmements."

But you could always say:
* "... while there are uninitialized elements"

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3472336926
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533786705
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533801082
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533773546
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533830776
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533836397
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533841573
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533846906
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533855814
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533865784

From pminborg at openjdk.org  Mon Nov 17 13:34:30 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 13:34:30 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
 <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>
Message-ID: <6LpdzFJhGUHodyEKeOMXvKH9nYsPhz7oDM6k4NpNsNE=.2f8b7bd1-2886-48b7-9f97-22b3b8ed7368@github.com>

On Mon, 17 Nov 2025 12:16:52 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 1:
> 
>> 1: /*
> 
> Side note: I'm slightly surprised to see the introduction and the usage happening in the same PR. Is this really being submitting in one go?

I've replaced `StableValue` with `LazyConstant`. So there is no new introduction, but just an adaptation.

> src/java.base/share/classes/java/nio/charset/Charset.java line 619:
> 
>> 617: 
>> 618:     private static final LazyConstant<Charset> defaultCharset = LazyConstant.of(
>> 619:             new Supplier<>() { public Charset get() { return defaultCharset0(); }});
> 
> Can these not be done with lambdas?

They can, but I wanted to keep it verbatim to the existing code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534085547
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534087249

From bpb at openjdk.org  Mon Nov 17 16:51:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Nov 2025 16:51:14 GMT
Subject: Integrated: 8371689: (fs) CopyMoveHelper.copyToForeignTarget use of
 sourcePosixView is confusing
In-Reply-To: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
References: <Bs7sT08k9atYUC1J-QGGsSaWKoPyoY2tzq9HcSjEez8=.3021db6e-8e37-48a5-ab9b-dc833ff1aac6@github.com>
Message-ID: <65gIXuxU96q73o8Dn6sNHcwjt5zPdAMJE7dbhcEH97A=.cfb68c9d-6d17-4eae-be2c-211b95d7fd46@github.com>

On Thu, 13 Nov 2025 18:57:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `CopyMoveHelper`, replace `PosixFileAttributeView` with a `boolean`.

This pull request has now been integrated.

Changeset: 9ec773ad
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ec773ad27773f5813c79ae33ac1d2393c2e0cc8
Stats:     9 lines in 1 file changed: 1 ins; 1 del; 7 mod

8371689: (fs) CopyMoveHelper.copyToForeignTarget use of sourcePosixView is confusing

Reviewed-by: alanb

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

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

From jvernee at openjdk.org  Mon Nov 17 16:52:17 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 16:52:17 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <ESX4NSuqv_AXuodz38Wfa56U1Asqs9g44MiZeUSEZ3Y=.fe99ad0c-a3f2-41e5-99da-7af83e6845e9@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

test/jdk/java/lang/LazyConstant/LazyConstantTest.java line 234:

> 232:             return new Lazy<>(LazyConstant.of(computingFunction));
> 233:         }
> 234:     }

This appears to be unused?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534822362

From jvernee at openjdk.org  Mon Nov 17 17:11:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 17:11:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <VGv5qMEBjKT1FLCasY2G79nWj_AlN_8SmDHmfAJa1HM=.ec050ca4-d07f-4b29-92ff-2cf972045023@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by jvernee (Reviewer).

test/jdk/java/lang/LazyConstant/LazyListTest.java line 27:

> 25:  * @summary Basic tests for lazy list methods
> 26:  * @enablePreview
> 27:  * @run junit/othervm --add-opens java.base/java.util=ALL-UNNAMED LazyListTest

I think you can do this with

Suggestion:

 * @modules java.base/java.util:+open
 * @run junit LazyListTest

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3473667773
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534826477

From bpb at openjdk.org  Mon Nov 17 18:56:24 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Nov 2025 18:56:24 GMT
Subject: RFR: 8372012:
 java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java should check
 ability to create links
Message-ID: <1Z7-VTctDxAARskyN3YGehO9-ggdHnyDrELlCyAUmz0=.fd6977ee-c623-426b-a160-fed07bbd8a33@github.com>

Invoke `TestUtil.supportsSymbolicLinks` before calling `Files.createSymbolicLink`.

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

Commit messages:
 - 8371145: java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java should check ability to create links

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

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

From alanb at openjdk.org  Mon Nov 17 19:22:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 19:22:36 GMT
Subject: RFR: 8372012:
 java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java should check
 ability to create links
In-Reply-To: <1Z7-VTctDxAARskyN3YGehO9-ggdHnyDrELlCyAUmz0=.fd6977ee-c623-426b-a160-fed07bbd8a33@github.com>
References: <1Z7-VTctDxAARskyN3YGehO9-ggdHnyDrELlCyAUmz0=.fd6977ee-c623-426b-a160-fed07bbd8a33@github.com>
Message-ID: <Rvks8fuiIw1juWFt6jGwGfMuUyh0cmVKwWDRCA3nuuM=.7c46df70-0563-4c8d-86ee-b2ec5d15cb9b@github.com>

On Mon, 17 Nov 2025 18:34:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Invoke `TestUtil.supportsSymbolicLinks` before calling `Files.createSymbolicLink`.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28360#pullrequestreview-3474224831

From bpb at openjdk.org  Mon Nov 17 20:26:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Nov 2025 20:26:57 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v18]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <IuoxMcptxkzLxVzHpPhRRztqRKzIqN4Onu1TyfK5bis=.ebcf5b34-c7f1-4f36-aa2a-40ed7e8516a3@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 18 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 8 more: https://git.openjdk.org/jdk/compare/9ec773ad...75555455

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

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

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

From syan at openjdk.org  Tue Nov 18 03:21:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Nov 2025 03:21:40 GMT
Subject: RFR: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux [v8]
In-Reply-To: <7vXsQCjHAtxfmqomuRLtvn158J7Sw-d56ERKG3DLrho=.9447009a-873c-4938-8028-38c043c3523d@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
 <Xrft6f7K537j8P6bUH9e_Y8Os0yZSBUW5sCBcKhX3wA=.193233e0-e923-43ae-a9fc-a0a876b162c6@github.com>
 <7vXsQCjHAtxfmqomuRLtvn158J7Sw-d56ERKG3DLrho=.9447009a-873c-4938-8028-38c043c3523d@github.com>
Message-ID: <6DJy1Cm3C7XaGCX_dZvB1mrU3wSu9HpeIpusF98OCiM=.928836c5-01ff-4c67-90a2-98271fda95b1@github.com>

On Mon, 17 Nov 2025 07:30:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Asserts.assertTrue instead of Asserts.assertNotNull
>
> I should have been clearer in my comments. If this test is changed to jdk.test.lib.Asserts then I think we should remove the local assertTrue method. The simplest is to just `import static jdk.test.lib.Asserts.*` and remove the local assertTrue method, it should just work.  The assertNotNull in the previous iteration was good, and better than assertTrue as you get a better diagnostic in the event of a failure.

Thanks for the suggestions and reviews @AlanBateman

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

PR Comment: https://git.openjdk.org/jdk/pull/28281#issuecomment-3544846643

From syan at openjdk.org  Tue Nov 18 03:21:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Nov 2025 03:21:40 GMT
Subject: Integrated: 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails
 after 8360887 on linux
In-Reply-To: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
References: <-H6lIdXWG4k2-5LGiQAoahtLpMX5sYzgGVIEHfWAPXQ=.df69d0be-6b49-455d-b228-6f4c53e37162@github.com>
Message-ID: <USlf_VVgo55ebi-uKpbPaonpoEXuhtAKXxoDrYEBBFM=.c1cb7794-369b-4689-bc4e-a378fcc22190@github.com>

On Thu, 13 Nov 2025 03:54:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The new method testFileAttributes in test/jdk/java/nio/file/FileStore/Basic.java added by [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887)/[JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183) fails on some linux machines. A FileSystemProvider may support many views but some of these attributes in these views may not supported on all FileStores.
> 
> Change has been verified locally on linux-aarch64.

This pull request has now been integrated.

Changeset: 46b5e588
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46b5e588ab18a68d164b1d97e71d769585c7c4b8
Stats:     11 lines in 1 file changed: 4 ins; 5 del; 2 mod

8371697: test/jdk/java/nio/file/FileStore/Basic.java fails after 8360887 on linux

Reviewed-by: alanb

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

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

From jpai at openjdk.org  Tue Nov 18 05:20:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Nov 2025 05:20:11 GMT
Subject: RFR: 8372012:
 java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java should check
 ability to create links
In-Reply-To: <1Z7-VTctDxAARskyN3YGehO9-ggdHnyDrELlCyAUmz0=.fd6977ee-c623-426b-a160-fed07bbd8a33@github.com>
References: <1Z7-VTctDxAARskyN3YGehO9-ggdHnyDrELlCyAUmz0=.fd6977ee-c623-426b-a160-fed07bbd8a33@github.com>
Message-ID: <u8AnbLKsQYUkqx5wQH3m1XNCsudb7RaT6wNRbOqBC10=.4e022036-91b0-4a95-96bd-da5a5f9fa754@github.com>

On Mon, 17 Nov 2025 18:34:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Invoke `TestUtil.supportsSymbolicLinks` before calling `Files.createSymbolicLink`.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28360#pullrequestreview-3475498041

From duke at openjdk.org  Tue Nov 18 11:14:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 18 Nov 2025 11:14:53 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <bwaH6vYcIoTgJYP82UEA0OOsghn-xAy6nFcrNACU-Js=.a38419f2-9c6d-4dfd-8d3c-997c69aff313@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Wrt. replacing?`StableValue` with?a?`VarHandle` access?mode, that?has the?downside of?the?variable not?being constant?foldable[^1], as?the?`@Stable`?annotation is?only?available to?the?system?domain class?loaders (bootstrap?and?platform).

[^1]: Without making?use of?`-Xbootclasspath/a:?`.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547013114

From pminborg at openjdk.org  Tue Nov 18 12:19:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Nov 2025 12:19:34 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <hZs96XTneTVOWiWq1dpNb_TbEKh-mkqg0MeWj-2vE-c=.2d7207dd-dc84-40af-b360-96c4c0e26a8e@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

> Wrt. replacing?`StableValue` with?a?`VarHandle` access?mode, that?has the?downside of?the?variable not?being constant?foldable[1](#user-content-fn-1-dd52c5569368829688622e7b8db815eb), as?the?`@Stable`?annotation is?only?available to?the?system?domain class?loaders (bootstrap?and?platform).

We think we can solve that. Stay tuned.

I will integrate this PR now.

There are outstanding comments in this PR that I will address in a separate follow-up PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547354435
PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547357897

From pminborg at openjdk.org  Tue Nov 18 12:24:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Nov 2025 12:24:52 GMT
Subject: Integrated: 8366178: Implement JEP 526: Lazy Constants (Second
 Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <q_NHVMDzKC3YXrUppwHly5ADB4eB7ohZhcxi6wPN8kA=.92e38494-ced1-4c6b-8d80-28409de8888e@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

This pull request has now been integrated.

Changeset: f9464499
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f94644999766e752f7d60ce52c14a7db79005035
Stats:     8347 lines in 60 files changed: 3738 ins; 4490 del; 119 mod

8366178: Implement JEP 526: Lazy Constants (Second Preview)
8371882: Improve documentation for JEP 526: Lazy Constants

Reviewed-by: jvernee, mcimadamore

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

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

From clanger at openjdk.org  Tue Nov 18 14:07:42 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 18 Nov 2025 14:07:42 GMT
Subject: RFR: 8317838: java/nio/channels/Channels/SocketChannelStreams.java
 running into timeout (aix)
Message-ID: <jlHCoqDJ2uoSKb1Z8k-1lpWxqYtfx0Q650DthC0Nttg=.7dbaa019-0c91-4ded-8a52-edc6fc61b914@github.com>

This removes the problemlist entry for AIX because the underlying issue was solved by OS patches.

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

Commit messages:
 - JDK-8317838

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

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

From bpb at openjdk.org  Tue Nov 18 15:15:43 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Nov 2025 15:15:43 GMT
Subject: Integrated: 8372012:
 java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java should check
 ability to create links
In-Reply-To: <1Z7-VTctDxAARskyN3YGehO9-ggdHnyDrELlCyAUmz0=.fd6977ee-c623-426b-a160-fed07bbd8a33@github.com>
References: <1Z7-VTctDxAARskyN3YGehO9-ggdHnyDrELlCyAUmz0=.fd6977ee-c623-426b-a160-fed07bbd8a33@github.com>
Message-ID: <UGo65eh1xGx7B9F5AeBNa4PNCl32MKG5K9bi7DvGtYs=.bcc44116-b64e-45b8-b302-2f5c044b4798@github.com>

On Mon, 17 Nov 2025 18:34:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Invoke `TestUtil.supportsSymbolicLinks` before calling `Files.createSymbolicLink`.

This pull request has now been integrated.

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

8372012: java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java should check ability to create links

Reviewed-by: alanb, jpai

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

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

From bpb at openjdk.org  Tue Nov 18 17:47:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Nov 2025 17:47:15 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more obvious
 that it fails when the directory already exists
Message-ID: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>

Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.

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

Commit messages:
 - 8220816: (fs) Files.createDirectory should make it more obvious that it fails when the directory already exists

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

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

From bpb at openjdk.org  Tue Nov 18 17:53:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Nov 2025 17:53:51 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v2]
In-Reply-To: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
Message-ID: <1WV4wFO_2e6Q9pDgC3kvZbE6HE0nCoWmOjV5a4_NoZM=.53ef4289-f37e-47d1-9d99-983acea65bd6@github.com>

> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.

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

  8220816: "directory" -> "file or directory"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28378/files
  - new: https://git.openjdk.org/jdk/pull/28378/files/4ab0ccb8..358bea7d

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

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

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

From jlu at openjdk.org  Tue Nov 18 21:48:14 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Nov 2025 21:48:14 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v2]
In-Reply-To: <1WV4wFO_2e6Q9pDgC3kvZbE6HE0nCoWmOjV5a4_NoZM=.53ef4289-f37e-47d1-9d99-983acea65bd6@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <1WV4wFO_2e6Q9pDgC3kvZbE6HE0nCoWmOjV5a4_NoZM=.53ef4289-f37e-47d1-9d99-983acea65bd6@github.com>
Message-ID: <bHgXxKjvpAJRKmwRHIlDw-cypI_tD6Fy9PgNfNJDzWM=.86cfcb3d-74ba-44d7-9db5-c4811d505db0@github.com>

On Tue, 18 Nov 2025 17:53:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: "directory" -> "file or directory"

Wording looks reasonable to me. I presume the CSR will be filed after wording is finalized.

src/java.base/share/classes/java/nio/file/Files.java line 640:

> 638:      *          when creating the directory
> 639:      * @throws  FileAlreadyExistsException
> 640:      *          if a directory could not otherwise be created because a file of

Is it worth clarifying ..."file _or directory_"... in the `throws` tag as well?

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

PR Review: https://git.openjdk.org/jdk/pull/28378#pullrequestreview-3479777478
PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2539701953

From bpb at openjdk.org  Tue Nov 18 22:05:11 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Nov 2025 22:05:11 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v2]
In-Reply-To: <bHgXxKjvpAJRKmwRHIlDw-cypI_tD6Fy9PgNfNJDzWM=.86cfcb3d-74ba-44d7-9db5-c4811d505db0@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <1WV4wFO_2e6Q9pDgC3kvZbE6HE0nCoWmOjV5a4_NoZM=.53ef4289-f37e-47d1-9d99-983acea65bd6@github.com>
 <bHgXxKjvpAJRKmwRHIlDw-cypI_tD6Fy9PgNfNJDzWM=.86cfcb3d-74ba-44d7-9db5-c4811d505db0@github.com>
Message-ID: <sjP9mE_8FvEjVNs5lALsSJUmPdQUFOPja7M-7lzD9r8=.eaa5ba41-4b75-4d24-9687-bc1e04e13303@github.com>

On Tue, 18 Nov 2025 21:25:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> I presume the CSR will be filed after wording is finalized.

Yes. I generally wait for the discussion to converge before filing the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3549609921

From bpb at openjdk.org  Tue Nov 18 22:09:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Nov 2025 22:09:17 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v2]
In-Reply-To: <1WV4wFO_2e6Q9pDgC3kvZbE6HE0nCoWmOjV5a4_NoZM=.53ef4289-f37e-47d1-9d99-983acea65bd6@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <1WV4wFO_2e6Q9pDgC3kvZbE6HE0nCoWmOjV5a4_NoZM=.53ef4289-f37e-47d1-9d99-983acea65bd6@github.com>
Message-ID: <SdStUZZivERHnxqiWCenlkXECuGhvkhXK6EI4ZCE5Ss=.023afc6c-67ce-4084-934d-7c0436018f45@github.com>

On Tue, 18 Nov 2025 17:53:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: "directory" -> "file or directory"

Please note that this was discussed before on [nio-dev](https://mail.openjdk.org/pipermail/nio-dev/2020-January/007008.html).

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3549622422

From bpb at openjdk.org  Tue Nov 18 22:09:19 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Nov 2025 22:09:19 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v2]
In-Reply-To: <bHgXxKjvpAJRKmwRHIlDw-cypI_tD6Fy9PgNfNJDzWM=.86cfcb3d-74ba-44d7-9db5-c4811d505db0@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <1WV4wFO_2e6Q9pDgC3kvZbE6HE0nCoWmOjV5a4_NoZM=.53ef4289-f37e-47d1-9d99-983acea65bd6@github.com>
 <bHgXxKjvpAJRKmwRHIlDw-cypI_tD6Fy9PgNfNJDzWM=.86cfcb3d-74ba-44d7-9db5-c4811d505db0@github.com>
Message-ID: <inDSPh_2u5VQUFm37SGoiofSyr0v3oQ-gwS2Gu-jnBM=.b48cf739-5e48-40c4-bfeb-659c36924021@github.com>

On Tue, 18 Nov 2025 21:23:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Is it worth clarifying ..."file _or directory_"... in the `throws` tag as well?

Yes, I think so, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2539767153

From bpb at openjdk.org  Tue Nov 18 22:14:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Nov 2025 22:14:22 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v3]
In-Reply-To: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
Message-ID: <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>

> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.

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

  8220816: Update throws verbiage to match

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28378/files
  - new: https://git.openjdk.org/jdk/pull/28378/files/358bea7d..3af34903

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

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

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

From bpb at openjdk.org  Tue Nov 18 22:14:23 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Nov 2025 22:14:23 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v2]
In-Reply-To: <inDSPh_2u5VQUFm37SGoiofSyr0v3oQ-gwS2Gu-jnBM=.b48cf739-5e48-40c4-bfeb-659c36924021@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <1WV4wFO_2e6Q9pDgC3kvZbE6HE0nCoWmOjV5a4_NoZM=.53ef4289-f37e-47d1-9d99-983acea65bd6@github.com>
 <bHgXxKjvpAJRKmwRHIlDw-cypI_tD6Fy9PgNfNJDzWM=.86cfcb3d-74ba-44d7-9db5-c4811d505db0@github.com>
 <inDSPh_2u5VQUFm37SGoiofSyr0v3oQ-gwS2Gu-jnBM=.b48cf739-5e48-40c4-bfeb-659c36924021@github.com>
Message-ID: <EQVs1tylq1PXARg1bdrrTCr9ThqJ7-nLufuSZV-z1Wc=.013cd279-9371-4644-928f-da606bcf072b@github.com>

On Tue, 18 Nov 2025 22:05:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/Files.java line 640:
>> 
>>> 638:      *          when creating the directory
>>> 639:      * @throws  FileAlreadyExistsException
>>> 640:      *          if a directory could not otherwise be created because a file of
>> 
>> Is it worth clarifying ..."file _or directory_"... in the `throws` tag as well?
>
>> Is it worth clarifying ..."file _or directory_"... in the `throws` tag as well?
> 
> Yes, I think so, thanks.

Changed in commit 3af3490.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2539779343

From rriggs at openjdk.org  Wed Nov 19 01:38:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Nov 2025 01:38:01 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v3]
In-Reply-To: <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>
Message-ID: <hNu7gWZm28Ur9HRF-ZAntYXeOWDXxc2nDipH-4IldLE=.b624b9e9-b40c-4851-af7e-82346ca4fcb4@github.com>

On Tue, 18 Nov 2025 22:14:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Update throws verbiage to match

src/java.base/share/classes/java/nio/file/Files.java line 640:

> 638:      *          when creating the directory
> 639:      * @throws  FileAlreadyExistsException
> 640:      *          if a directory could not otherwise be created because a file or

It is pre-existing wording, but I don't know that "otherwise" has any meaning here.
It reads the same whether "otherwise" is present or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2540146604

From alanb at openjdk.org  Wed Nov 19 10:34:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Nov 2025 10:34:30 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v3]
In-Reply-To: <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>
Message-ID: <-EO1ckq-7V0fV5YY-Ec82l0M4HKpqa2-OPt2Nk_AJtU=.de994cf2-4162-40f6-977b-5bef4936e65f@github.com>

On Tue, 18 Nov 2025 22:14:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Update throws verbiage to match

I think the `@throws FileAlreadyExistsException` description could be improved as "because a file of that name already exists" is too subtle. If we do change it then it will need to be done for all the methods that throw this exception, not just Files.createDirectory. What do you think of keeping it as simple as "If `dir` locates a file that already exists" ?

Files.createFile has "Creates a new and empty file, failing if the file already exists", which I think is clear. It's less easy to create a sentence for createDirectory, createSymbolicFile and other methods. "Creates a directory, failing if the file already exists" is accurate but might not be clear to everyone that "file" means any file (sym link, directory, ...). I wonder if we keep it to "Creates a directory, failing if `dir` locates an existing file".  I would be hesitate to using "file or directory" as proposed because that's just two of many cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3551973453

From alanb at openjdk.org  Wed Nov 19 15:00:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Nov 2025 15:00:11 GMT
Subject: RFR: 8317838: java/nio/channels/Channels/SocketChannelStreams.java
 running into timeout (aix)
In-Reply-To: <jlHCoqDJ2uoSKb1Z8k-1lpWxqYtfx0Q650DthC0Nttg=.7dbaa019-0c91-4ded-8a52-edc6fc61b914@github.com>
References: <jlHCoqDJ2uoSKb1Z8k-1lpWxqYtfx0Q650DthC0Nttg=.7dbaa019-0c91-4ded-8a52-edc6fc61b914@github.com>
Message-ID: <ezrh4aYRVcWdk7Kf-SIHWUL1xAos4BW4Wutm-UcjZo8=.2fa971de-bf4a-4e72-a488-b3ebb9ead1c3@github.com>

On Tue, 18 Nov 2025 13:25:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This removes the problemlist entry for AIX because the underlying issue was solved by OS patches.

The removal looks okay. I see the issue was solved by an OS update so I wonder if this JBS issue should get renamed to say that it removes the test from the ProblemList?

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28370#pullrequestreview-3483225502

From mdoerr at openjdk.org  Wed Nov 19 16:13:26 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Nov 2025 16:13:26 GMT
Subject: RFR: 8317838: java/nio/channels/Channels/SocketChannelStreams.java
 running into timeout (aix)
In-Reply-To: <jlHCoqDJ2uoSKb1Z8k-1lpWxqYtfx0Q650DthC0Nttg=.7dbaa019-0c91-4ded-8a52-edc6fc61b914@github.com>
References: <jlHCoqDJ2uoSKb1Z8k-1lpWxqYtfx0Q650DthC0Nttg=.7dbaa019-0c91-4ded-8a52-edc6fc61b914@github.com>
Message-ID: <OqBUziok2U18M8b41aaBiMNXrJeioBX7hbl4biQZ6ok=.149b6686-c6d9-4a27-bede-02a55f9b3c1c@github.com>

On Tue, 18 Nov 2025 13:25:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This removes the problemlist entry for AIX because the underlying issue was solved by OS patches.

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28370#pullrequestreview-3483594447

From bpb at openjdk.org  Wed Nov 19 16:53:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 16:53:10 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v3]
In-Reply-To: <-EO1ckq-7V0fV5YY-Ec82l0M4HKpqa2-OPt2Nk_AJtU=.de994cf2-4162-40f6-977b-5bef4936e65f@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>
 <-EO1ckq-7V0fV5YY-Ec82l0M4HKpqa2-OPt2Nk_AJtU=.de994cf2-4162-40f6-977b-5bef4936e65f@github.com>
Message-ID: <B3O4kOIbgC3wIhI6MrYcKk6LnNm_5PfMECUibe36sgo=.5e4b17f1-43a1-48ce-bf53-131628702ee0@github.com>

On Wed, 19 Nov 2025 10:32:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> What do you think of keeping it as simple as "If `dir` locates a file that already exists" ?

That's fine. I previously suggested `{@code dir}` already exists [here](https://cr.openjdk.org/~bpb/8220816/webrev.00/src/java.base/share/classes/java/nio/file/Files.java.udiff.html).

> "Creates a directory, failing if `dir` locates an existing file".

That might work.

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3553687946

From bpb at openjdk.org  Wed Nov 19 16:53:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 16:53:12 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v3]
In-Reply-To: <hNu7gWZm28Ur9HRF-ZAntYXeOWDXxc2nDipH-4IldLE=.b624b9e9-b40c-4851-af7e-82346ca4fcb4@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>
 <hNu7gWZm28Ur9HRF-ZAntYXeOWDXxc2nDipH-4IldLE=.b624b9e9-b40c-4851-af7e-82346ca4fcb4@github.com>
Message-ID: <0Sf9rNg4XZNjeerLo1CUrdph76q0TihmXmKvw3pqWyM=.c1aceb40-d72c-4fa5-beea-19b8f7ff4891@github.com>

On Wed, 19 Nov 2025 01:35:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I don't know that "otherwise" has any meaning here.

No, I also don't think it does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2542788284

From bpb at openjdk.org  Wed Nov 19 18:12:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 18:12:34 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v3]
In-Reply-To: <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <hkwgeOU1uKVk7Dv94VG4Fa8bXbgktGPXmuxryKkwubo=.09c66e91-8190-48ba-a656-5a3a7fc21a8c@github.com>
Message-ID: <79cl0Gd6xlrIkDrDhM1FPzpJ8PccSGqViScVFqXamzU=.ac532d42-335e-44e5-bdf2-89e5079cd4e7@github.com>

On Tue, 18 Nov 2025 22:14:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Update throws verbiage to match

Commit 5c62cd5 does not (yet) address `throws FileAlreadyExistsException` verbiage for these cases:

1. If a file of that name already exists and the CREATE_NEW option is specified;
2. if the target file exists but cannot be replaced because the REPLACE_EXISTING option is not specified.

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3553974779

From bpb at openjdk.org  Wed Nov 19 18:12:32 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 18:12:32 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v4]
In-Reply-To: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
Message-ID: <3EsoKGDApj5qTcKnqmiJhTFh5UtaOm61IytXf3-nI9A=.d3f4a30d-ecf1-41cf-afa5-21a18b3ec0f8@github.com>

> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.

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

  8220816: Improve consistency per review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28378/files
  - new: https://git.openjdk.org/jdk/pull/28378/files/3af34903..5c62cd5f

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

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

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

From alanb at openjdk.org  Wed Nov 19 18:55:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Nov 2025 18:55:16 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v4]
In-Reply-To: <3EsoKGDApj5qTcKnqmiJhTFh5UtaOm61IytXf3-nI9A=.d3f4a30d-ecf1-41cf-afa5-21a18b3ec0f8@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <3EsoKGDApj5qTcKnqmiJhTFh5UtaOm61IytXf3-nI9A=.d3f4a30d-ecf1-41cf-afa5-21a18b3ec0f8@github.com>
Message-ID: <IWKfLfRisa6aUAR7wOv83Wl-TXRvuGHbA10v4HZVIuE=.c819a5a1-eb11-42ca-a9a8-b2658ac51605@github.com>

On Wed, 19 Nov 2025 18:12:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Improve consistency per review comments

src/java.base/share/classes/java/nio/file/Files.java line 579:

> 577:     /**
> 578:      * Creates a new and empty file, failing if {@code path} locates an existing
> 579:      * file. The

That works. I assume you'll re-flow this a bit to avoid "file. The"  be on its own.

src/java.base/share/classes/java/nio/file/Files.java line 681:

> 679:      *          when creating the directory
> 680:      * @throws  FileAlreadyExistsException
> 681:      *          if {@code dir} locates an existing file but is not a directory

Maybe "that is not a directory" might be better.

src/java.base/share/classes/java/nio/file/Files.java line 985:

> 983:     /**
> 984:      * Creates a new link (directory entry) for an existing file,
> 985:     * failing if {@code link} locates an existing file <i>(optional

Minor nit, I think the comment has got mis-aligned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2543185333
PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2543183191
PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2543187478

From bpb at openjdk.org  Wed Nov 19 19:03:08 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 19:03:08 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v4]
In-Reply-To: <IWKfLfRisa6aUAR7wOv83Wl-TXRvuGHbA10v4HZVIuE=.c819a5a1-eb11-42ca-a9a8-b2658ac51605@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <3EsoKGDApj5qTcKnqmiJhTFh5UtaOm61IytXf3-nI9A=.d3f4a30d-ecf1-41cf-afa5-21a18b3ec0f8@github.com>
 <IWKfLfRisa6aUAR7wOv83Wl-TXRvuGHbA10v4HZVIuE=.c819a5a1-eb11-42ca-a9a8-b2658ac51605@github.com>
Message-ID: <Aot7Py2u7elvTKrPPUiFXnWmePvNkadgteQ90HoIAoU=.0da95f66-78fe-47da-b26e-d56379f5010c@github.com>

On Wed, 19 Nov 2025 18:51:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you'll re-flow this a bit

I left it that way intentionally to ease comparing the diffs in progress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2543207749

From bpb at openjdk.org  Wed Nov 19 19:17:20 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 19:17:20 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v4]
In-Reply-To: <Aot7Py2u7elvTKrPPUiFXnWmePvNkadgteQ90HoIAoU=.0da95f66-78fe-47da-b26e-d56379f5010c@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <3EsoKGDApj5qTcKnqmiJhTFh5UtaOm61IytXf3-nI9A=.d3f4a30d-ecf1-41cf-afa5-21a18b3ec0f8@github.com>
 <IWKfLfRisa6aUAR7wOv83Wl-TXRvuGHbA10v4HZVIuE=.c819a5a1-eb11-42ca-a9a8-b2658ac51605@github.com>
 <Aot7Py2u7elvTKrPPUiFXnWmePvNkadgteQ90HoIAoU=.0da95f66-78fe-47da-b26e-d56379f5010c@github.com>
Message-ID: <_nJB3aiPk-88deD8RSbWyxY6EQbdNrKg2uMfU4mSJkg=.49b431f6-96b1-4183-9b58-c9fb3b191df3@github.com>

On Wed, 19 Nov 2025 18:59:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/Files.java line 579:
>> 
>>> 577:     /**
>>> 578:      * Creates a new and empty file, failing if {@code path} locates an existing
>>> 579:      * file. The
>> 
>> That works. I assume you'll re-flow this a bit to avoid "file. The"  be on its own.
>
>> I assume you'll re-flow this a bit
> 
> I left it that way intentionally to ease comparing the diffs in progress.

Fixed in 9cf6ede.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2543247431

From bpb at openjdk.org  Wed Nov 19 19:17:23 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 19:17:23 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v4]
In-Reply-To: <IWKfLfRisa6aUAR7wOv83Wl-TXRvuGHbA10v4HZVIuE=.c819a5a1-eb11-42ca-a9a8-b2658ac51605@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <3EsoKGDApj5qTcKnqmiJhTFh5UtaOm61IytXf3-nI9A=.d3f4a30d-ecf1-41cf-afa5-21a18b3ec0f8@github.com>
 <IWKfLfRisa6aUAR7wOv83Wl-TXRvuGHbA10v4HZVIuE=.c819a5a1-eb11-42ca-a9a8-b2658ac51605@github.com>
Message-ID: <nhYG4gEbe1M_cIqleaFLJJjZTfg8YuGTunAN00_bdL8=.ac430d79-398b-49cb-9929-0df9e688f670@github.com>

On Wed, 19 Nov 2025 18:50:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8220816: Improve consistency per review comments
>
> src/java.base/share/classes/java/nio/file/Files.java line 681:
> 
>> 679:      *          when creating the directory
>> 680:      * @throws  FileAlreadyExistsException
>> 681:      *          if {@code dir} locates an existing file but is not a directory
> 
> Maybe "that is not a directory" might be better.

Fixed in 9cf6ede.

> src/java.base/share/classes/java/nio/file/Files.java line 985:
> 
>> 983:     /**
>> 984:      * Creates a new link (directory entry) for an existing file,
>> 985:     * failing if {@code link} locates an existing file <i>(optional
> 
> Minor nit, I think the comment has got mis-aligned.

Fixed in 9cf6ede.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2543247140
PR Review Comment: https://git.openjdk.org/jdk/pull/28378#discussion_r2543247558

From bpb at openjdk.org  Wed Nov 19 19:17:18 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 19:17:18 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v5]
In-Reply-To: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
Message-ID: <-eC01PRd0mR6KmGnyHKu2bvboKM3twTON8JAUBkMK-0=.b4c6140b-3eab-44fe-8404-42dfd3fe71c0@github.com>

> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.

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

  8220816: Address more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28378/files
  - new: https://git.openjdk.org/jdk/pull/28378/files/5c62cd5f..9cf6ede5

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

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

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

From alanb at openjdk.org  Wed Nov 19 19:25:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Nov 2025 19:25:49 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v5]
In-Reply-To: <-eC01PRd0mR6KmGnyHKu2bvboKM3twTON8JAUBkMK-0=.b4c6140b-3eab-44fe-8404-42dfd3fe71c0@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <-eC01PRd0mR6KmGnyHKu2bvboKM3twTON8JAUBkMK-0=.b4c6140b-3eab-44fe-8404-42dfd3fe71c0@github.com>
Message-ID: <nSxonCPQm344dRv2XHtBu40vG7DCaX19XhgFZ3-Aba0=.228fa4e4-b4c6-4b5f-9c43-0b0e5504702c@github.com>

On Wed, 19 Nov 2025 19:17:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Address more review comments

Good, thanks for the updates.

A coin toss as to whether it needs a CSR as there isn't anything new or changed.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28378#pullrequestreview-3484376181

From bpb at openjdk.org  Wed Nov 19 19:28:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 19:28:22 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v5]
In-Reply-To: <nSxonCPQm344dRv2XHtBu40vG7DCaX19XhgFZ3-Aba0=.228fa4e4-b4c6-4b5f-9c43-0b0e5504702c@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <-eC01PRd0mR6KmGnyHKu2bvboKM3twTON8JAUBkMK-0=.b4c6140b-3eab-44fe-8404-42dfd3fe71c0@github.com>
 <nSxonCPQm344dRv2XHtBu40vG7DCaX19XhgFZ3-Aba0=.228fa4e4-b4c6-4b5f-9c43-0b0e5504702c@github.com>
Message-ID: <DtCs9TQo9ET5nOZ23g4Z_x7-YFIzYgxO3sNSyMOJXc4=.356ab1c7-b5fd-4e3d-880b-3dd34a1d2712@github.com>

On Wed, 19 Nov 2025 19:23:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Good, thanks for the updates.

Thanks for the review.

Are we not concerned about the other FAEEs mentioned [above](https://github.com/openjdk/jdk/pull/28378#issuecomment-3553974779)?

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3554294557

From alanb at openjdk.org  Wed Nov 19 19:49:21 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Nov 2025 19:49:21 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v5]
In-Reply-To: <DtCs9TQo9ET5nOZ23g4Z_x7-YFIzYgxO3sNSyMOJXc4=.356ab1c7-b5fd-4e3d-880b-3dd34a1d2712@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <-eC01PRd0mR6KmGnyHKu2bvboKM3twTON8JAUBkMK-0=.b4c6140b-3eab-44fe-8404-42dfd3fe71c0@github.com>
 <nSxonCPQm344dRv2XHtBu40vG7DCaX19XhgFZ3-Aba0=.228fa4e4-b4c6-4b5f-9c43-0b0e5504702c@github.com>
 <DtCs9TQo9ET5nOZ23g4Z_x7-YFIzYgxO3sNSyMOJXc4=.356ab1c7-b5fd-4e3d-880b-3dd34a1d2712@github.com>
Message-ID: <R7sAAHKZEQaVjgKIox-WZpSpamCyH2OGe4etrhZNXgA=.520d3b13-4ed2-4d1e-9f08-1dfeafad5283@github.com>

On Wed, 19 Nov 2025 19:26:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Are we not concerned about the other FAEEs mentioned [above](https://github.com/openjdk/jdk/pull/28378#issuecomment-3553974779)?

Some of them are okay, e.g. copy has "if the target file exists but ...". 

If you have cycles, there are 7 cases that have "If a file of that name already exists and the CREATE_NEW ..." that could be improved if changed to "If the path locates an existing file and the CREATE_NEW ...".

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3554361666

From bpb at openjdk.org  Wed Nov 19 20:04:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 20:04:39 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v5]
In-Reply-To: <-eC01PRd0mR6KmGnyHKu2bvboKM3twTON8JAUBkMK-0=.b4c6140b-3eab-44fe-8404-42dfd3fe71c0@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <-eC01PRd0mR6KmGnyHKu2bvboKM3twTON8JAUBkMK-0=.b4c6140b-3eab-44fe-8404-42dfd3fe71c0@github.com>
Message-ID: <xJwXdmVJ01Xde-r2-HMoBB8wEtbMaIYng7gwJiGv10Q=.b6b0e7f1-be67-48ef-8c33-a1cea9b81221@github.com>

On Wed, 19 Nov 2025 19:17:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Address more review comments

> If you have cycles, there are 7 cases [...] that could be improved [...]

Yes, I will change them.

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3554420000

From bpb at openjdk.org  Wed Nov 19 20:13:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 20:13:42 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v6]
In-Reply-To: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
Message-ID: <tW0HzhXZq63V35zVVutZ5qVQFXWref2kxJel5sMnNVQ=.79d10bfb-0986-42d5-8104-3dd9023ac9dc@github.com>

> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.

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

  8220816: Change FAEE for CREATE_NEW cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28378/files
  - new: https://git.openjdk.org/jdk/pull/28378/files/9cf6ede5..3684b8c7

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

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

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

From alanb at openjdk.org  Wed Nov 19 20:13:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Nov 2025 20:13:42 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v6]
In-Reply-To: <tW0HzhXZq63V35zVVutZ5qVQFXWref2kxJel5sMnNVQ=.79d10bfb-0986-42d5-8104-3dd9023ac9dc@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <tW0HzhXZq63V35zVVutZ5qVQFXWref2kxJel5sMnNVQ=.79d10bfb-0986-42d5-8104-3dd9023ac9dc@github.com>
Message-ID: <OyNiTfJIfS9eMd239UsnD6mMxMOZsKW-U4ex7HAeVQ4=.3bb73f8e-7f9b-457b-84c3-29178dc4c23c@github.com>

On Wed, 19 Nov 2025 20:10:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Change FAEE for CREATE_NEW cases

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28378#pullrequestreview-3484548967

From bpb at openjdk.org  Wed Nov 19 20:13:43 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 19 Nov 2025 20:13:43 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v5]
In-Reply-To: <R7sAAHKZEQaVjgKIox-WZpSpamCyH2OGe4etrhZNXgA=.520d3b13-4ed2-4d1e-9f08-1dfeafad5283@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <-eC01PRd0mR6KmGnyHKu2bvboKM3twTON8JAUBkMK-0=.b4c6140b-3eab-44fe-8404-42dfd3fe71c0@github.com>
 <nSxonCPQm344dRv2XHtBu40vG7DCaX19XhgFZ3-Aba0=.228fa4e4-b4c6-4b5f-9c43-0b0e5504702c@github.com>
 <DtCs9TQo9ET5nOZ23g4Z_x7-YFIzYgxO3sNSyMOJXc4=.356ab1c7-b5fd-4e3d-880b-3dd34a1d2712@github.com>
 <R7sAAHKZEQaVjgKIox-WZpSpamCyH2OGe4etrhZNXgA=.520d3b13-4ed2-4d1e-9f08-1dfeafad5283@github.com>
Message-ID: <VK_Tj9OqN7wR2TjAhImkEKSSySeohARtjZvKWqhiK3I=.b23d1a34-fe86-47e9-bf90-bce02836e1c7@github.com>

On Wed, 19 Nov 2025 19:46:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If you have cycles, there are 7 cases that have "If a file of that name already exists and the CREATE_NEW ..." that could be improved if changed to "If the path locates an existing file and the CREATE_NEW ...".

Addressed in commit 3684b8c.

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3554443834

From jpai at openjdk.org  Thu Nov 20 09:26:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 09:26:05 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v6]
In-Reply-To: <tW0HzhXZq63V35zVVutZ5qVQFXWref2kxJel5sMnNVQ=.79d10bfb-0986-42d5-8104-3dd9023ac9dc@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <tW0HzhXZq63V35zVVutZ5qVQFXWref2kxJel5sMnNVQ=.79d10bfb-0986-42d5-8104-3dd9023ac9dc@github.com>
Message-ID: <-jdeioxspijKSkns6JK_LiJ--XqeEYanhHy_0g-HFG0=.177db2a8-8be0-452c-a74f-25f97e7e3626@github.com>

On Wed, 19 Nov 2025 20:13:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Change FAEE for CREATE_NEW cases

Hello Brian, the changes look reasonable to me.

Having said that, the JBS issue description states that the usage of the word "file" makes it sound like the exception is raised only if a regular file exists at the `Path`. Specifically, the previous wording was:

> If a file of that name already exists

and with the proposed change we now have:

> If the path locates an existing file

So, I think, that wording will still leave readers wondering whether existing directory at that `Path` are considered when throwing that exception. 

I am not proposing further changes though (I can't think of something that's more concise). `Files.exists(Path)` too uses the word "file":

> Tests whether a file exists.

and it checks even for directories, so I think it's all consistent with the rest of the API docs.

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3556829441

From alanb at openjdk.org  Thu Nov 20 09:35:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Nov 2025 09:35:14 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v6]
In-Reply-To: <-jdeioxspijKSkns6JK_LiJ--XqeEYanhHy_0g-HFG0=.177db2a8-8be0-452c-a74f-25f97e7e3626@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <tW0HzhXZq63V35zVVutZ5qVQFXWref2kxJel5sMnNVQ=.79d10bfb-0986-42d5-8104-3dd9023ac9dc@github.com>
 <-jdeioxspijKSkns6JK_LiJ--XqeEYanhHy_0g-HFG0=.177db2a8-8be0-452c-a74f-25f97e7e3626@github.com>
Message-ID: <siceWcF8FusLJOkl-1tmMsASyraE6_8yQ9FGQrL-wzA=.1695f83d-315c-4036-8323-ae66c1cad5c7@github.com>

On Thu, 20 Nov 2025 09:23:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Having said that, the JBS issue description states that the usage of the word "file" makes it sound like the exception is raised only if a regular file exists 

I think it's best to keep the API docs simple and consistent. I'm sure there are developers that don't think of a directory or sym files as "files" but once you attempt to clarify things then it gets complicated and it could potentially confusing a wider set of developers.

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

PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3556871476

From jpai at openjdk.org  Thu Nov 20 09:44:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 09:44:46 GMT
Subject: RFR: 8220816: (fs) Files.createDirectory should make it more
 obvious that it fails when the directory already exists [v6]
In-Reply-To: <tW0HzhXZq63V35zVVutZ5qVQFXWref2kxJel5sMnNVQ=.79d10bfb-0986-42d5-8104-3dd9023ac9dc@github.com>
References: <OfBLyDnYbKGGW0T_RU7HI1XGInM0OebmXd3XpOxPCFM=.46425659-379d-43f4-b5c1-96bfde951cd3@github.com>
 <tW0HzhXZq63V35zVVutZ5qVQFXWref2kxJel5sMnNVQ=.79d10bfb-0986-42d5-8104-3dd9023ac9dc@github.com>
Message-ID: <XQMMUhTZsanEa-wYpdEj7mm0PlOhrs7cq9RPitqZLMM=.3351b5be-4396-4df1-9d43-130661ae1fc3@github.com>

On Wed, 19 Nov 2025 20:13:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8220816: Change FAEE for CREATE_NEW cases

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28378#pullrequestreview-3486677304

From duke at openjdk.org  Thu Nov 20 11:48:35 2025
From: duke at openjdk.org (serhiysachkov)
Date: Thu, 20 Nov 2025 11:48:35 GMT
Subject: RFR: 8371629: Add diagnostic output
 IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels
 directory -- part I
Message-ID: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>

Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I

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

Commit messages:
 - 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I

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

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

From jpai at openjdk.org  Thu Nov 20 12:00:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 12:00:16 GMT
Subject: RFR: 8371629: Add diagnostic output
 IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels
 directory -- part I
In-Reply-To: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
References: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
Message-ID: <nt9jZ_wweuvtAmFBbJ3G5yWFi4m2k9FDvuAtQRvdytg=.060876b6-5ae8-48fa-a259-94be764b0f3d@github.com>

On Thu, 20 Nov 2025 10:34:46 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I

Hello Serhiy, my opinion is that we shouldn't be adding this change to every single test file.
When a test is run, typically in CI or locally, it runs as part of several other tests on a specific host. The `IPSupport.printPlatformSupport(...)` prints host specific details and not test specific details, so calling this in every single test would generate redundant output and would require update and future additions to every single test within the networking area. 

If this information isn't already captured in the jtreg failure handlers of the JDK, then I think we should enhance those failure handlers so that this same information gets collected just once when there is a test failure or a timeout. That I think should avoid all these test updates.

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

PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3557626595

From dfuchs at openjdk.org  Thu Nov 20 12:26:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:21 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v2]
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <fbZzaZTDoy8CE5Q-391sOVBezopxpDa7ggDCKJ2R3po=.cac468b3-953b-491f-8bb5-05b3222db78b@github.com>

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

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

 - Merge branch 'SelectorManagerVT-8372159' into ConnectionCloseLock-8372198
 - 8372198: Avoid closing PlainHttpConnection while holding a lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28421/files
  - new: https://git.openjdk.org/jdk/pull/28421/files/177e7ee3..97ce3737

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

  Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/28421.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421

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

From dfuchs at openjdk.org  Thu Nov 20 12:26:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:22 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <BEkaPOGOa8LRlqic4jsZvlx97AR8RVfNhjk5_1Kvips=.741bab98-7b90-4f2c-aadc-c93d62650091@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Something went wrong when I tried to merge the main PR branch in the dependent PR branch. I'm going to withdraw this PR and start again.

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

PR Comment: https://git.openjdk.org/jdk/pull/28421#issuecomment-3557752299

From dfuchs at openjdk.org  Thu Nov 20 12:26:23 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:23 GMT
Subject: Withdrawn: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <S8TUGJh8rmGEbyRwrMCP7SaPKA6HJG8O_HHX17gFyDw=.2eb7031f-a01d-42d1-8efc-1b49466b48dc@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Nov 20 12:43:53 2025
From: duke at openjdk.org (serhiysachkov)
Date: Thu, 20 Nov 2025 12:43:53 GMT
Subject: RFR: 8371629: Add diagnostic output
 IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels
 directory -- part I
In-Reply-To: <nt9jZ_wweuvtAmFBbJ3G5yWFi4m2k9FDvuAtQRvdytg=.060876b6-5ae8-48fa-a259-94be764b0f3d@github.com>
References: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
 <nt9jZ_wweuvtAmFBbJ3G5yWFi4m2k9FDvuAtQRvdytg=.060876b6-5ae8-48fa-a259-94be764b0f3d@github.com>
Message-ID: <JF5LH_8k0gJJ6f3cp0wOSVTGe2WX1aZXuMkb_HS213M=.c65c238d-56ba-4449-ad90-c3c6e9744c46@github.com>

On Thu, 20 Nov 2025 11:57:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Serhiy, my opinion is that we shouldn't be adding this change to every single test file. When a test is run, typically in CI or locally, it runs as part of several other tests on a specific host. The `IPSupport.printPlatformSupport(...)` prints host specific details and not test specific details, so calling this in every single test would generate redundant output and would require update and future additions to every single test within the networking area.
> 
> If this information isn't already captured in the jtreg failure handlers of the JDK, then I think we should enhance those failure handlers so that this same information gets collected just once when there is a test failure or a timeout. That I think should avoid all these test updates.

Hi Jaikiran, this output would help during ATR failure analysis, as experience of previous ones shows there are a lot of communication going on during this period on env setup especially in IPv6 testing, so the idea is to save some time for those back and forward communications in clearing out testing environments when 3rd party is involved in testing. Plus it's a background for future changes, that will involve runs with specific JVM option as -Djava.net.PreferIPv6Addresses in IPV6 only and mixed env.

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

PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3557840486

From msheppar at openjdk.org  Thu Nov 20 13:01:44 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 20 Nov 2025 13:01:44 GMT
Subject: RFR: 8371629: Add diagnostic output
 IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels
 directory -- part I
In-Reply-To: <nt9jZ_wweuvtAmFBbJ3G5yWFi4m2k9FDvuAtQRvdytg=.060876b6-5ae8-48fa-a259-94be764b0f3d@github.com>
References: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
 <nt9jZ_wweuvtAmFBbJ3G5yWFi4m2k9FDvuAtQRvdytg=.060876b6-5ae8-48fa-a259-94be764b0f3d@github.com>
Message-ID: <UPBYC7KRjfnma7D_J9000l9nWYvQhNHdOfHir8ip4f0=.c9c4882f-c292-4899-9805-7ba621951015@github.com>

On Thu, 20 Nov 2025 11:57:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I
>
> Hello Serhiy, my opinion is that we shouldn't be adding this change to every single test file.
> When a test is run, typically in CI or locally, it runs as part of several other tests on a specific host. The `IPSupport.printPlatformSupport(...)` prints host specific details and not test specific details, so calling this in every single test would generate redundant output and would require update and future additions to every single test within the networking area. 
> 
> If this information isn't already captured in the jtreg failure handlers of the JDK, then I think we should enhance those failure handlers so that this same information gets collected just once when there is a test failure or a timeout. That I think should avoid all these test updates.

@jaikiran This is not just about test failures in IPv6 environments, but also that the test that pass are also correctly passing.
It will also assist in diagnosing failures in the CI pipelines. It is to assist is determining if anomalous behaviour is due to a dynamic configuration change in a test environment. It is to ensure that there is a consistent configuration and setup during the execution of the networking tests in an IPv6 only env.
Ask yourself why there are so many TCP4 connections rather than TCP4,6 connections in the failures associated with https://bugs.openjdk.org/browse/JDK-8273158 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3557926075

From alanb at openjdk.org  Thu Nov 20 14:33:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Nov 2025 14:33:00 GMT
Subject: RFR: 8371629: Add diagnostic output
 IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels
 directory -- part I
In-Reply-To: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
References: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
Message-ID: <1mrIlQMT85mj-s4V4ys5T0f8Qbt811XkDJXr3gA1zCQ=.735c80d7-6790-4510-8168-5618b43e15ef@github.com>

On Thu, 20 Nov 2025 10:34:46 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I

I have my doubts on the usefulness of this as IPSupport.printPlatformSupport doesn't print the network configuration. If there is dynamic reconfiguration going on (and I agree that is hard to diagnose) then dumping the network configuration in the jtreg failure handler would be useful if it's not there already.

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

PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3558353546

From alanb at openjdk.org  Thu Nov 20 14:37:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Nov 2025 14:37:19 GMT
Subject: RFR: 8371629: Add diagnostic output
 IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels
 directory -- part I
In-Reply-To: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
References: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
Message-ID: <nmnA-QI6M2dfyUofmN108Pwd-XEd05Qj2O1kmeQZaQU=.7e15304f-bb92-4e4f-9a68-0552bb83f275@github.com>

On Thu, 20 Nov 2025 10:34:46 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I

test/jdk/java/nio/channels/AsynchronousSocketChannel/CompletionHandlerRelease.java line 154:

> 152:     @BeforeClass
> 153:     void printSupportedPlatforms(){
> 154:         IPSupport.printPlatformSupport(System.out);

FYI: JUnit prints to System.err rather than System.out so need to specify System.err to get it inlined in the output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28420#discussion_r2546263841

From msheppar at openjdk.org  Thu Nov 20 15:23:45 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 20 Nov 2025 15:23:45 GMT
Subject: RFR: 8371629: Add diagnostic output
 IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels
 directory -- part I
In-Reply-To: <1mrIlQMT85mj-s4V4ys5T0f8Qbt811XkDJXr3gA1zCQ=.735c80d7-6790-4510-8168-5618b43e15ef@github.com>
References: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
 <1mrIlQMT85mj-s4V4ys5T0f8Qbt811XkDJXr3gA1zCQ=.735c80d7-6790-4510-8168-5618b43e15ef@github.com>
Message-ID: <ASokEYSE6Paj4Raa6DV-rQg7VlEBcBkXed8GE4s_C9w=.df1a9b72-8c8a-452e-8df5-1a19269ea223@github.com>

On Thu, 20 Nov 2025 14:29:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I have my doubts on the usefulness of this as IPSupport.printPlatformSupport doesn't print the network configuration. If there is dynamic reconfiguration going on (and I agree that is hard to diagnose) then dumping the network configuration in the jtreg failure handler would be useful if it's not there already.

Yes, the network configuration is printed in the jtreg handler. BUT, wrt this addition, we are not looking for network configuration (at this juncture). We wish to determine what is the "perception" of the JDK runtime, used in the test, wrt IPv4 and IPv6 support and correlate that with the configuration i.e. IPv6 only. Has it created a socket in the correct  domain etc., has the OS been (accidentally) altered to enable IPv4, while it may not have it configured. If preferIPv4Stack is set true, why has a test not failed.

Additionally, this is not just for failures. It is also to allow review of successful test execution, and to ensure the consistency of behaviour within IPv6 only environments.

Prior to running test in IPv6 only environments, we run a set of sanity checks, which are set standalone tests verifying the configured environments. We capture the network configuration for comparison with the jtreg failure capture. 

We do a lot of preparation to ensure the env are setup correctly. But anomalies have been observed, which have raised question on the veracity of the tests. 

This change is to assist in evaluating the test JDK runtime thinks it is using and what has been configured.

It's a small addition which goes a long way to helping the analysis

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

PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3558633339

From duke at openjdk.org  Fri Nov 21 11:22:26 2025
From: duke at openjdk.org (serhiysachkov)
Date: Fri, 21 Nov 2025 11:22:26 GMT
Subject: RFR: 8371629: Add diagnostic output
 IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels
 directory -- part I
In-Reply-To: <nmnA-QI6M2dfyUofmN108Pwd-XEd05Qj2O1kmeQZaQU=.7e15304f-bb92-4e4f-9a68-0552bb83f275@github.com>
References: <KA4V3HmWTkCiTVpFqhG-XdjdM2PbKxyojm1SjnunnUs=.02b2c534-ec4e-4c5e-b83c-652991ee2604@github.com>
 <nmnA-QI6M2dfyUofmN108Pwd-XEd05Qj2O1kmeQZaQU=.7e15304f-bb92-4e4f-9a68-0552bb83f275@github.com>
Message-ID: <AAc2GdZ8XENM8D-jYsClzL-NvNrla4TLQq6Su-Sbs_w=.b735ec30-534d-46b2-a242-df96b150b8c5@github.com>

On Thu, 20 Nov 2025 14:24:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I
>
> test/jdk/java/nio/channels/AsynchronousSocketChannel/CompletionHandlerRelease.java line 154:
> 
>> 152:     @BeforeClass
>> 153:     void printSupportedPlatforms(){
>> 154:         IPSupport.printPlatformSupport(System.out);
> 
> FYI: JUnit prints to System.err rather than System.out so need to specify System.err to get it inlined in the output.

We will be able to update it when test will be refactored to use JUnit instead of TestNG as part of further improvements mentioned above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28420#discussion_r2549429470

From clanger at openjdk.org  Thu Nov 27 15:47:00 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 27 Nov 2025 15:47:00 GMT
Subject: RFR: 8317838: java/nio/channels/Channels/SocketChannelStreams.java
 running into timeout (aix)
In-Reply-To: <ezrh4aYRVcWdk7Kf-SIHWUL1xAos4BW4Wutm-UcjZo8=.2fa971de-bf4a-4e72-a488-b3ebb9ead1c3@github.com>
References: <jlHCoqDJ2uoSKb1Z8k-1lpWxqYtfx0Q650DthC0Nttg=.7dbaa019-0c91-4ded-8a52-edc6fc61b914@github.com>
 <ezrh4aYRVcWdk7Kf-SIHWUL1xAos4BW4Wutm-UcjZo8=.2fa971de-bf4a-4e72-a488-b3ebb9ead1c3@github.com>
Message-ID: <vDGSpGaIBx90sdtp1Iik8-xCPga2Ibsz7E7HGihGgHY=.23515ef0-8812-4970-9b3b-4588685aad7a@github.com>

On Wed, 19 Nov 2025 14:58:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The removal looks okay. I see the issue was solved by an OS update so I wonder if this JBS issue should get renamed to say that it removes the test from the ProblemList?

Thanks for the reviews. I don't want to change the bug title/synopsis. If we'd like to document that it's a problem list removal only, we should create a new issue but I think it's not worth the additional effort. People looking at the issue will figure it out. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28370#issuecomment-3586514434

From clanger at openjdk.org  Thu Nov 27 15:47:01 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 27 Nov 2025 15:47:01 GMT
Subject: Integrated: 8317838:
 java/nio/channels/Channels/SocketChannelStreams.java running into timeout
 (aix)
In-Reply-To: <jlHCoqDJ2uoSKb1Z8k-1lpWxqYtfx0Q650DthC0Nttg=.7dbaa019-0c91-4ded-8a52-edc6fc61b914@github.com>
References: <jlHCoqDJ2uoSKb1Z8k-1lpWxqYtfx0Q650DthC0Nttg=.7dbaa019-0c91-4ded-8a52-edc6fc61b914@github.com>
Message-ID: <gnFZu0z3z4-1s1GJTRYv1PvE0OBy-i7zC7l4wh_82Lc=.021e034e-dbb9-42ea-9206-6aeb0ad3e61f@github.com>

On Tue, 18 Nov 2025 13:25:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This removes the problemlist entry for AIX because the underlying issue was solved by OS patches.

This pull request has now been integrated.

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

8317838: java/nio/channels/Channels/SocketChannelStreams.java running into timeout (aix)

Reviewed-by: alanb, mdoerr

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

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