From bpb at openjdk.org Wed Oct 1 16:43:10 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 1 Oct 2025 16:43:10 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v16] In-Reply-To: References: Message-ID: > 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 16 commits: - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8337143: Minor makefile tweak - 8337143: Clean up to address reviewer comments - ... and 6 more: https://git.openjdk.org/jdk/compare/fe9dbcc4...498be60b ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=15 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 naoto at openjdk.org Wed Oct 1 20:01:58 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Oct 2025 20:01:58 GMT Subject: RFR: 8368845: x-IBM930 uses incorrect character for Hex 42 60 Message-ID: <0Ep8UN3_bJ-nR9RCNIUaRA7flGGV3khNSjstui2ijRk=.d3eb41c7-1bae-4916-9c80-876d5912724f@github.com> Fixing a charset en/decoder for x-IBM930. There was a "temporary" mapping for the said code point for the backward compatibility (as of JDK7). Since the issue requests the "correct" mapping, I believe we can replace the temporary one with the correct mapping. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/27594/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27594&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368845 Stats: 15 lines in 3 files changed: 0 ins; 13 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27594/head:pull/27594 PR: https://git.openjdk.org/jdk/pull/27594 From jlu at openjdk.org Wed Oct 1 20:43:05 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Oct 2025 20:43:05 GMT Subject: RFR: 8368845: x-IBM930 uses incorrect character for Hex 42 60 In-Reply-To: <0Ep8UN3_bJ-nR9RCNIUaRA7flGGV3khNSjstui2ijRk=.d3eb41c7-1bae-4916-9c80-876d5912724f@github.com> References: <0Ep8UN3_bJ-nR9RCNIUaRA7flGGV3khNSjstui2ijRk=.d3eb41c7-1bae-4916-9c80-876d5912724f@github.com> Message-ID: On Wed, 1 Oct 2025 19:50:49 GMT, Naoto Sato wrote: > Fixing a charset en/decoder for x-IBM930. There was a "temporary" mapping for the said code point for the backward compatibility (as of JDK7). Since the issue requests the "correct" mapping, I believe we can replace the temporary one with the correct mapping. Should we add a test to confirm the swap to the new behavior? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27594#issuecomment-3358062301 From naoto at openjdk.org Wed Oct 1 21:06:19 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Oct 2025 21:06:19 GMT Subject: RFR: 8368845: x-IBM930 uses incorrect character for Hex 42 60 [v2] In-Reply-To: <0Ep8UN3_bJ-nR9RCNIUaRA7flGGV3khNSjstui2ijRk=.d3eb41c7-1bae-4916-9c80-876d5912724f@github.com> References: <0Ep8UN3_bJ-nR9RCNIUaRA7flGGV3khNSjstui2ijRk=.d3eb41c7-1bae-4916-9c80-876d5912724f@github.com> Message-ID: > Fixing a charset en/decoder for x-IBM930. There was a "temporary" mapping for the said code point for the backward compatibility (as of JDK7). Since the issue requests the "correct" mapping, I believe we can replace the temporary one with the correct mapping. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: added bugid to the tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27594/files - new: https://git.openjdk.org/jdk/pull/27594/files/bd338444..30ba5ce5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27594&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27594&range=00-01 Stats: 7 lines in 3 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27594/head:pull/27594 PR: https://git.openjdk.org/jdk/pull/27594 From naoto at openjdk.org Wed Oct 1 21:06:21 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Oct 2025 21:06:21 GMT Subject: RFR: 8368845: x-IBM930 uses incorrect character for Hex 42 60 In-Reply-To: References: <0Ep8UN3_bJ-nR9RCNIUaRA7flGGV3khNSjstui2ijRk=.d3eb41c7-1bae-4916-9c80-876d5912724f@github.com> Message-ID: On Wed, 1 Oct 2025 20:40:39 GMT, Justin Lu wrote: > Should we add a test to confirm the swap to the new behavior? I had added the test data for the new mapping (Cp930.b2c) which is used for several test cases. Added the bug id to the relevant tests which should make it clearer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27594#issuecomment-3358124998 From sherman at openjdk.org Fri Oct 3 19:10:20 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 3 Oct 2025 19:10:20 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support Message-ID: ### Summary Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: **String.equalsIgnoreCase(String)** - Unicode-aware, locale-independent. - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. - Limited: does not support 1:M mapping defined in Unicode case folding. **Character.toLowerCase(int) / Character.toUpperCase(int)** - Locale-independent, single code point only. - No support for 1:M mappings. **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** - Based on Unicode SpecialCasing.txt, supports 1:M mappings. - Intended primarily for presentation/display, not structural case-insensitive matching. - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. **1:M mapping example, U+00DF (?)** - String.toUpperCase(Locale.ROOT, "?") ? "SS" - Case folding produces "ss", matching Unicode caseless comparison rules. jshell> "\u00df".equalsIgnoreCase("ss") $22 ==> false jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") $24 ==> true ### Motivation & Direction Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. - Unicode-compliant **full** case folding. - Simpler, stable and more efficient case-less matching without workarounds. - Brings Java's string comparison handling in line with other programming languages/libraries. This PR proposes to introduce the following comparison methods in `String` class - boolean equalsFoldCase(String anotherString) - int compareToFoldCase(String anotherString) - Comparator UNICODE_CASEFOLD_ORDER These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate. ### The New API /** * Compares this {@code String} to another {@code String} for equality, * using Unicode case folding. Two strings are considered equal * by this method if their case-folded forms are identical. *

* Case folding is defined by the Unicode Standard in * CaseFolding.txt, * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")} * returns {@code true}, since the character {@code U+00DF} (sharp s) folds * to {@code "ss"}. *

* Case folding is locale-independent and language-neutral, unlike * locale-sensitive transformations such as {@link #toLowerCase()} or * {@link #toUpperCase()}. It is intended for caseless matching, * searching, and indexing. * * @apiNote * This method is the Unicode-compliant alternative to * {@link #equalsIgnoreCase(String)}. It implements full case folding as * defined by the Unicode Standard, which may differ from the simpler * per-character mapping performed by {@code equalsIgnoreCase}. * For example: *

{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }

* * @param anotherString * The {@code String} to compare this {@code String} against * * @return {@code true} if the given object is not {@code null} and represents * the same sequence of characters as this string under Unicode case * folding; {@code false} otherwise. * * @see #compareToFoldCase(String) * @see #equalsIgnoreCase(String) * @since 26 */ public boolean equalsFoldCase(String anotherString) /** * Compares two strings lexicographically using Unicode case folding. * This method returns an integer whose sign is that of calling {@code compareTo} * on the Unicode case folded version of the strings. Unicode Case folding * eliminates differences in case according to the Unicode Standard, using the * mappings defined in * CaseFolding.txt, * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}. *

* Case folding is a locale-independent, language-neutral form of case mapping, * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)}, * which applies a simpler locale-insensitive uppercase mapping. This method * follows the Unicode full case folding, providing stable and * consistent results across all environments. *

* Note that this method does not take locale into account, and may * produce results that differ from locale-sensitive ordering. Use * {@link java.text.Collator} for locale-sensitive comparison. * * @apiNote * This method is the Unicode-compliant alternative to * {@link #compareToIgnoreCase(String)}. It implements the full case folding * as defined by the Unicode Standard, which may differ from the simpler * per-character mapping performed by {@code compareToIgnoreCase}. * For example: *

{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }

Message-ID: On Thu, 9 Oct 2025 08:37:51 GMT, Aleksei Voitylov wrote: >> This cleanup replaces #ifdefs with a standard #include . Using standard types is less prone to errors. >> >> JDK-8368522 was reported on ARM32 with musl libc, which is not a supported configuration, but I still believe this code cleanup is worth it. >> >> After the introduction of statx with musl 1.2.5, a buffer overflow issue with statx() call handling started happening on ARM32. The root cause is incorrect size of __uint64_t type definition in the JDK for musl libc, where it was defined as 4 bytes (unsigned long int) for 32-bit systems instead of 8 bytes (unsigned long long). >> >> The mismatch between JDK's my_statx structure and kernel's statx structure causes stack corruption when statx() writes beyond the statx_buf boundaries, overwriting adjacent variables, including the 'attrs' argument that was later passed to copy_statx_attributes() function and caused a segfault there. >> >> Built and ran jtreg on standard OpenJDK platforms with no regressions, including the altered test. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments This looks good to me. src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 58: > 56: > 57: #ifdef __linux__ > 58: #include Suggestion: #include // For uint_XX_t types used in statx support ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27674#pullrequestreview-3317813237 PR Review Comment: https://git.openjdk.org/jdk/pull/27674#discussion_r2416000199 From avoitylov at openjdk.org Thu Oct 9 08:41:41 2025 From: avoitylov at openjdk.org (Aleksei Voitylov) Date: Thu, 9 Oct 2025 08:41:41 GMT Subject: RFR: 8368522: (fs) BasicFileAttributes Linux musl 1.2.5 incompatibility with statx [v2] In-Reply-To: References:

Message-ID: On Thu, 9 Oct 2025 09:41:42 GMT, Alan Bateman wrote: > Have you considered adding a JMH benchmark for exercising toRealPath and toRealPath(NOFOLLOW_LINKS)? Yes, but I didn't do it. It should be straightforward to add. > If the name and element are not equal then I think it has to use file key. Do you intend that file key alone should be used here and drop toString? Is it possible that equalsIgnoreCase returns false when the file keys are equal? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27709#issuecomment-3386267503 PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2417129911 From bpb at openjdk.org Thu Oct 9 15:44:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 9 Oct 2025 15:44:28 GMT Subject: RFR: 8368522: (fs) BasicFileAttributes Linux musl 1.2.5 incompatibility with statx [v4] In-Reply-To: References:

Message-ID: On Thu, 9 Oct 2025 15:26:05 GMT, Brian Burkhalter wrote: >> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 965: >> >>> 963: path = path.resolve(entry); >>> 964: break; >>> 965: } else if (name.toString().equalsIgnoreCase(elementName)) { >> >> The compareTo at L961 looks right but the using toString is problematic here as it may be lossy. If the name and element are not equal then I think it has to use file key. > >> If the name and element are not equal then I think it has to use file key. > > Do you intend that file key alone should be used here and drop toString? Is it possible that equalsIgnoreCase returns false when the file keys are equal? I think the compareTo == 0 to see byte representation is equal is good, that will avoid the stat to get the fileKey. The concern with the String/equalsIgnoreCase is that there may be false positives. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2417211249 From bpb at openjdk.org Thu Oct 9 15:59:59 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 9 Oct 2025 15:59:59 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS In-Reply-To: References:

Message-ID: On Thu, 9 Oct 2025 15:47:48 GMT, Alan Bateman wrote: > The concern with the String/equalsIgnoreCase is that there may be false positives. But wouldn't it be the false negatives that would be the problem? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2417239068 From alanb at openjdk.org Thu Oct 9 16:08:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Oct 2025 16:08:45 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS In-Reply-To: References:

Message-ID: On Thu, 9 Oct 2025 15:57:29 GMT, Brian Burkhalter wrote: >> I think the compareTo == 0 to see byte representation is equal is good, that will avoid the stat to get the fileKey. The concern with the String/equalsIgnoreCase is that there may be false positives. > >> The concern with the String/equalsIgnoreCase is that there may be false positives. > > But wouldn't it be the false negatives that would be the problem? It's both, I think the only way to avoid the stat call will be to compare the bytes (like the first check). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2417260920 From bpb at openjdk.org Thu Oct 9 16:16:20 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 9 Oct 2025 16:16:20 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS In-Reply-To: References:

Message-ID: On Thu, 9 Oct 2025 16:05:52 GMT, Alan Bateman wrote: > It's both, I think the only way to avoid the stat call will be to compare the bytes (like the first check). My thinking was that if `equalsIgnoreCase == false` then the file keys cannot be equal so there is no point checking them. If however `equalsIgnoreCase == true`, then the keys might or might not be equal and need to be checked. So the question is, if `equalsIgnoreCase == false` can the keys be equal? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2417287351 From bpb at openjdk.org Thu Oct 9 16:20:27 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 9 Oct 2025 16:20:27 GMT Subject: RFR: 8368522: (fs) BasicFileAttributes Linux musl 1.2.5 incompatibility with statx [v4] In-Reply-To: References:

Message-ID: <2gcWdADQ_7ec4TMhJoliDes8alZx8ig6-ZGvRDo4yns=.5ebb09b3-da83-4338-9fae-84b71c5eae26@github.com> On Thu, 9 Oct 2025 16:13:54 GMT, Brian Burkhalter wrote: > My thinking was that if equalsIgnoreCase == false then the file keys cannot be equal so there is no point checking them. The encode + decode may may not be a perfect round trip so I don't think this would hold. I think the only safe approach is to compareTo with the byte representation, if they are not equal then need to stat to get the fileKey. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2417713632 From bpb at openjdk.org Thu Oct 9 19:25:55 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 9 Oct 2025 19:25:55 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS In-Reply-To: <2gcWdADQ_7ec4TMhJoliDes8alZx8ig6-ZGvRDo4yns=.5ebb09b3-da83-4338-9fae-84b71c5eae26@github.com> References:

<2gcWdADQ_7ec4TMhJoliDes8alZx8ig6-ZGvRDo4yns=.5ebb09b3-da83-4338-9fae-84b71c5eae26@github.com> Message-ID: On Thu, 9 Oct 2025 19:04:11 GMT, Alan Bateman wrote: >>> It's both, I think the only way to avoid the stat call will be to compare the bytes (like the first check). >> >> My thinking was that if `equalsIgnoreCase == false` then the file keys cannot be equal so there is no point checking them. If however `equalsIgnoreCase == true`, then the keys might or might not be equal and need to be checked. So the question is, if `equalsIgnoreCase == false` can the keys be equal? > >> My thinking was that if equalsIgnoreCase == false then the file keys cannot be equal so there is no point checking them. > > The encode + decode may may not be a perfect round trip so I don't think this would hold. I think the only safe approach is to compareTo with the byte representation, if they are not equal then need to stat to get the fileKey. It's not a reason to go forward if the equalsIgnoreCase test is invalid, but dropping this check effectively negates the performance improvement. The path `element` is being compared to all the entries in a DirectoryStream and only one of them will have `compareTo == 0`, so all the rest encountered before the match will need their keys checked. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2417752383 From alanb at openjdk.org Fri Oct 10 08:13:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Oct 2025 08:13:50 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS In-Reply-To: References:

<2gcWdADQ_7ec4TMhJoliDes8alZx8ig6-ZGvRDo4yns=.5ebb09b3-da83-4338-9fae-84b71c5eae26@github.com> Message-ID: On Thu, 9 Oct 2025 19:23:30 GMT, Brian Burkhalter wrote: >>> My thinking was that if equalsIgnoreCase == false then the file keys cannot be equal so there is no point checking them. >> >> The encode + decode may may not be a perfect round trip so I don't think this would hold. I think the only safe approach is to compareTo with the byte representation, if they are not equal then need to stat to get the fileKey. > > It's not a reason to go forward if the equalsIgnoreCase test is invalid, but dropping this check effectively negates the performance improvement. The path `element` is being compared to all the entries in a DirectoryStream and only one of them will have `compareTo == 0`, so all the rest encountered before the match will need their keys checked. I don't have data to support this but I would expect that the element name will exactly match an entry in the directory most of the time. One thing to try is split it into two scans of the directory, the first uses compareTo on the byte representation, the second is the slow case when there is no match and you have to look at the fileKey. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2418861483 From avoitylov at openjdk.org Fri Oct 10 13:21:57 2025 From: avoitylov at openjdk.org (Aleksei Voitylov) Date: Fri, 10 Oct 2025 13:21:57 GMT Subject: RFR: 8368522: (fs) BasicFileAttributes Linux musl 1.2.5 incompatibility with statx [v4] In-Reply-To: References:

Message-ID: On Fri, 10 Oct 2025 23:02:24 GMT, Brian Burkhalter wrote: >> Try to avoid checking file keys for all entries by first attempting `Path.compareTo` and `String.equalsIgnoreCase`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368633: Compare byte representations first then file keys; add micro test/micro/org/openjdk/bench/java/nio/file/ToRealPath.java line 52: > 50: files[i] = p; > 51: } > 52: } You can use `@TearDown` to remove the files. I think we'll need the benchmark to exercise some longer paths. Also I think it will have to exercise case sensitive, in this case the benchmark invokes toRealPath on "rEALpATH". That should give you a couple of scenarios that exercise both the first and second iterations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2422547763 From pminborg at openjdk.org Mon Oct 13 11:51:02 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 11:51:02 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) Message-ID: 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. ------------- Commit messages: - Add optimization where the computing function is returned directly - Add benchmark of Optionals - Merge branch 'master' into lazy-constants - Update src/java.base/share/classes/java/lang/LazyConstant.java - Update src/java.base/share/classes/java/util/LazyCollections.java - Fix failing test - Clean up - Merge branch 'master' into lazy-constants - Update JEP number - Fix doc issues - ... and 76 more: https://git.openjdk.org/jdk/compare/1605e839...3e287031 Changes: https://git.openjdk.org/jdk/pull/27605/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366178 Stats: 8721 lines in 60 files changed: 4112 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 duke at openjdk.org Mon Oct 13 11:51:02 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 13 Oct 2025 11:51:02 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: <8VsjXECvVSYRtKpK4PId8s_8RM0T00n4BzmfO6RTinM=.e1bb59c4-8a85-4d3c-8980-249cd529b50b@github.com> On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. I?m?gonna?miss **Stable?Values**, as?it?has some?use?cases which?aren?t?served by?**Lazy?Constants**, and?on?which I?depend?on in?some of?my?code, so?I?m stuck?with using?regular non?`final`?fields. -------------------------------------------------------------------------------- Also, in the [JEP?526]?table under ?[Flexible?initialization with?lazy?constants]?: > | | Update count | Update location | Constant folding? | Concurrent updates? > | -------------- | ------------ | --------------- | ----------------- | ------------------- > | `final` field | 1 | Constructor or static initializer | Yes | No > | `LazyConstant` | [0, 1] | Anywhere | Yes, after initialization | Yes, by winner > | Non-`final` field | [0, ?) | Anywhere | No | Yes The??Update?location? of?`LazyConstant` shouldn?t?be??Anywhere?, as?that?was only?accurate for?`StableValue`, but?not for?`LazyConstant`, which?is?updated by?calling the?passed `Supplier`. Similarly, concurrent?updates are?prevented for?`LazyConstant`s by?using `synchronized?(this)`. [JEP?526]: https://openjdk.org/jeps/526 [Flexible?initialization with?lazy?constants]: https://openjdk.org/jeps/526#Flexible-initialization-with-lazy-constants Getting?access to?the?underlying `StableValue`?API with?**Lazy?Constants** is?way?too?hacky and?convoluted (but?doable):

StableVar.java

------------- PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3367784825 PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3368298279 From liach at openjdk.org Mon Oct 13 11:51:04 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 13 Oct 2025 11:51:04 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: <8VsjXECvVSYRtKpK4PId8s_8RM0T00n4BzmfO6RTinM=.e1bb59c4-8a85-4d3c-8980-249cd529b50b@github.com> References: <8VsjXECvVSYRtKpK4PId8s_8RM0T00n4BzmfO6RTinM=.e1bb59c4-8a85-4d3c-8980-249cd529b50b@github.com> Message-ID: On Sat, 4 Oct 2025 14:29:08 GMT, ExE Boss 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. > > Getting?access to?the?underlying `StableValue`?API with?**Lazy?Constants** is?way?too?hacky and?convoluted (but?doable): >

StableVar.java

> > > /* > * Any copyright is dedicated to the Public Domain. > * https://creativecommons.org/publicdomain/zero/1.0/ > */ > > import java.util.NoSuchElementException; > import java.util.function.Supplier; > > import org.jspecify.annotations.NullMarked; > import org.jspecify.annotations.Nullable; > > import static java.lang.System.identityHashCode; > import static java.util.Objects.requireNonNull; > > /// Horrible awful hack to get access to raw stable values in JDK 26+. > @NullMarked > public sealed interface StableVar permits StableHacks.StableVarImpl { > boolean trySet(final T contents) throws NullPointerException, IllegalStateException; > @Nullable T orNull(); > T orElse(final T other) throws NullPointerException; > T orElseThrow() throws NoSuchElementException; > boolean isSet(); > T orElseSet(final Supplier supplier) throws NullPointerException, IllegalStateException; > void setOrThrow(final T contents) throws NullPointerException, IllegalStateException; > > static StableVar of() { > return StableHacks.newInstance(); > } > } > > /// Encapsulates the actual implementation of `StableValue` on `LazyConstant` > /// > /// @author ExE Boss > @NullMarked > /*package*/ final @Namespace class StableHacks { > private StableHacks() throws InstantiationException { throw new InstantiationException(StableHacks.class.getName()); } > > private static final String UNSET_SUFFIX = ".unset"; > private static final Object UNSET = new Object() { > @Override > public int hashCode() { > return 0; > } > > @Override > public String toString() { > return "unset"; > } > }; > > private static final ScopedValue SCOPE = ScopedValue.newInstance(); > private static final Supplier SCOPE_GETTER = SCOPE::get; > > /*package*/ static final StableVarImpl newInstance() { > return new StableValue<>(); > } > > /*package*/ sealed interface StableVarImpl extends StableVar { > } > > private record StableValue( > // Implemented as a record so that the JVM treats this as a trusted final field > // even when `-XX:+TrustFinalNonStaticFields` is not set > LazyConstant contents > ) implements StableVarImpl { > @SuppressWarnings("unchecked") > private StableValue() { > this(LazyConstant.of((Supplier) SCOPE_GETTER)); > } > > private StableValue { > if (contents.isInitialized()) throw new InternalError(); > } > > @SuppressWarnings("unchecked") > private fi... Hi @ExE-Boss, this new JEP describes how this functionality will be provided in the future: > Lazy constants cover the common, high-level use cases for lazy initialization. In the future we might consider providing stable access semantics directly, at a lower level, for reference, array, and primitive fields. This would address, for example, use cases where the computing function associated with a lazy constant is not known at construction. This would be necessary, as there are usage patterns (such as nominal descriptors in ClassFile API) that would benefit from multiple assignment and a stable promoted read. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3368317631 From duke at openjdk.org Mon Oct 13 11:51:05 2025 From: duke at openjdk.org (Burning_TNT) Date: Mon, 13 Oct 2025 11:51:05 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. It's essential to provide a low-level API as those in StableValue. Completely migrating to factory pattern may forcing users to build their own LazyConstant wrapper as ExeBoss has down above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3369054838 From pminborg at openjdk.org Mon Oct 13 11:51:05 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 11:51:05 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: <5N4q67er51rXJ8E1oqNY4gCowyJ_K4x1SCeWncz1dFY=.2fe20197-fffe-467f-a1af-5816594c7e78@github.com> On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. > I?m?gonna?miss **Stable?Values**, as?it?has some?use?cases which?aren?t?served by?**Lazy?Constants**, and?on?which I?depend?on in?some of?my?code, so?I?m stuck?with using?regular non?`final`?fields. > > Also, in the [JEP?526](https://openjdk.org/jeps/526)?table under ?[Flexible?initialization with?lazy?constants](https://openjdk.org/jeps/526#Flexible-initialization-with-lazy-constants)?: > > > Update count > > Update location > > Constant folding? > > Concurrent updates? > > > > > > > > > > `final` field > > 1 > > Constructor or static initializer > > Yes > > No > > > > > > `LazyConstant` > > [0, 1] > > Anywhere > > Yes, after initialization > > Yes, by winner > > > > > > Non-`final` field > > [0, ?) > > Anywhere > > No > > Yes > > The??Update?location? of?`LazyConstant` shouldn?t?be??Anywhere?, as?that?was only?accurate for?`StableValue`, but?not for?`LazyConstant`, which?is?updated by?calling the?passed `Supplier`. > > Similarly, concurrent?updates are?prevented for?`LazyConstant`s by?using `synchronized?(this)`. I've updated the JEP. Thanks for pointing out this. Let me know what you think about the new text. We are exploring better ways to provide low-level, imperative, lazy constant/stable value fields. This work will be done outside the current JEP. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3396693041 PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3397160926 From duke at openjdk.org Mon Oct 13 11:51:06 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 13 Oct 2025 11:51:06 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: <5N4q67er51rXJ8E1oqNY4gCowyJ_K4x1SCeWncz1dFY=.2fe20197-fffe-467f-a1af-5816594c7e78@github.com> References: <5N4q67er51rXJ8E1oqNY4gCowyJ_K4x1SCeWncz1dFY=.2fe20197-fffe-467f-a1af-5816594c7e78@github.com> Message-ID: On Mon, 13 Oct 2025 09:49:16 GMT, Per Minborg wrote: > I've updated the JEP. Thanks for pointing out this. Let me know what you think about the new text. The?change was?made to?the?wrong?row (?Non?`final`?field? instead of??`LazyConstant`?). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3396866550 From fandreuzzi at openjdk.org Mon Oct 13 11:51:09 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Mon, 13 Oct 2025 11:51:09 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: <9oTBJDVY4LhEXsE4tVJAItdEvmaA3YcZ0BbUrw7M9uk=.86f99b3a-fbb2-4ce4-916d-e0487fce4211@github.com> On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. src/java.base/share/classes/java/lang/LazyConstant.java line 166: > 164: * > 165: *

Performance

> 166: * As a lazy constant can never change after it has been initialized. Therefore, Suggestion: * A lazy constant can never change after it has been initialized. Therefore, src/java.base/share/classes/java/util/LazyCollections.java line 80: > 78: } > 79: > 80: @Override public boolean isEmpty() { return size == 0;} Suggestion: @Override public boolean isEmpty() { return size == 0; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399059426 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399074220 From duke at openjdk.org Mon Oct 13 11:51:10 2025 From: duke at openjdk.org (Kerman) Date: Mon, 13 Oct 2025 11:51:10 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. src/java.base/share/classes/java/util/Optional.java line 74: > 72: * If non-null, the value; if null, indicates no value is present > 73: */ > 74: @Stable Shouldn?t this also add a null sentinel to allow the folding of the empty case? Or is that irrelevant because empty would be the terminator of a chain. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399352909 From liach at openjdk.org Mon Oct 13 11:51:11 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 13 Oct 2025 11:51:11 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References:

Message-ID: <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com> On Thu, 2 Oct 2025 16:16:44 GMT, Kerman 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. > > src/java.base/share/classes/java/util/Optional.java line 74: > >> 72: * If non-null, the value; if null, indicates no value is present >> 73: */ >> 74: @Stable > > Shouldn?t this also add a null sentinel to allow the folding of the empty case? Or is that irrelevant because empty would be the terminator of a chain. 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) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2403729792 From pminborg at openjdk.org Mon Oct 13 11:51:11 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 11:51:11 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com> References:

<-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com> Message-ID: On Sat, 4 Oct 2025 04:13:05 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/util/Optional.java line 74: >> >>> 72: * If non-null, the value; if null, indicates no value is present >>> 73: */ >>> 74: @Stable >> >> Shouldn?t this also add a null sentinel to allow the folding of the empty case? Or is that irrelevant because empty would be the terminator of a chain. > > 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_42 = LazyConstant.of(() -> Optional.of(42)); private static final LazyConstant> OPTIONAL_42_2 = LazyConstant.of(() -> Optional.of(42)); private static final LazyConstant> OPTIONAL_EMPTY = LazyConstant.of(Optional::empty); private static final LazyConstant> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426044826 From liach at openjdk.org Mon Oct 13 11:51:13 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 13 Oct 2025 11:51:13 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. src/java.base/share/classes/jdk/internal/lang/LazyConstantImpl.java line 171: > 169: > 170: public static LazyConstantImpl ofLazy(Supplier computingFunction) { > 171: return new LazyConstantImpl<>(computingFunction); We might return the function if it is already a LazyConstantImpl. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399678324 From duke at openjdk.org Mon Oct 13 11:51:14 2025 From: duke at openjdk.org (Jefferson Quesado) Date: Mon, 13 Oct 2025 11:51:14 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. src/java.base/share/classes/sun/nio/ch/Net.java line 99: > 97: } > 98: > 99: private static final LazyConstant SHUTDOWN_WRITE_BEFORE_CLOSE = LazyConstant.of(new Supplier() { I wonder if there is a reason for not using `BooleanSupplier`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399205774 From liach at openjdk.org Mon Oct 13 11:51:15 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 13 Oct 2025 11:51:15 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References:

> 98: * If the computing function throws any unchecked exception or Error, that Throwable add some code blocks around `Error` and `Throwable` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426369216 From mcimadamore at openjdk.org Mon Oct 13 13:40:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Oct 2025 13:40:54 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. src/java.base/share/classes/java/lang/LazyConstant.java line 155: > 153: * {@code final} fields of any newly created objects, are safely published. > 154: *

> 155: * The computing function runs on the caller?s thread. Here you might define "we call that thread the computing thread" -- this might be useful when defining other concepts in this section (maybe) src/java.base/share/classes/java/lang/LazyConstant.java line 157: > 155: * The computing function runs on the caller?s thread. > 156: *

> 157: * If a thread that is blocked by another computing thread is interrupted, this is not I'm not sure I understand what you mean in this para src/java.base/share/classes/java/lang/LazyConstant.java line 172: > 170: * (e.g. in cases where the lazy constant itself is stored in a > 171: * {@code static final} field) or forms a trusted chain to such a VM constant via > 172: * one or more layers of a {@linkplain Record record} fields or final fields one or more layers of "trusted" fields -- then in parenthesis you say what these "trusted" fields are. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426383095 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426379186 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426387301 From mcimadamore at openjdk.org Mon Oct 13 13:40:56 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Oct 2025 13:40:56 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 13:35:21 GMT, Maurizio Cimadamore 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. > > src/java.base/share/classes/java/lang/LazyConstant.java line 157: > >> 155: * The computing function runs on the caller?s thread. >> 156: *

>> 157: * If a thread that is blocked by another computing thread is interrupted, this is not > > I'm not sure I understand what you mean in this para E.g. "thread that is blocked by another computing thread". Did you mean to say "if the thread running the computing function is interrupted"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426381677 From mcimadamore at openjdk.org Mon Oct 13 13:46:48 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Oct 2025 13:46:48 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. src/java.base/share/classes/java/lang/LazyConstant.java line 188: > 186: * arbitrary depth can be used, which provides constant components. > 187: * More generally, a lazy constant can hold other lazy constants of > 188: * arbitrary depth and still provide transitive constancy. I'm not sure the term "constancy" is common to mean constant-ness. I think it might be better to use the term "constant-folding" -- and then define "constant-folding" in the above "performance" section: > A lazy constant can never change after it has been initialized. Therefore, > a JVM implementation may, for an initialized lazy constant, elide all future reads > of that lazy constant, and instead directly use any constant that it has previously > observed Then you can add "we call this optimization constant-folding". src/java.base/share/classes/java/lang/LazyConstant.java line 192: > 190: * The {@code LazyConstant} type is not {@link Serializable}. > 191: *

> 192: * It is not recommended putting lazy constants into equality-based collections Not sure what you mean here. It seems like the javadoc for `equals` says that it triggers initialization, so it should be ok? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426397976 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426402669 From pminborg at openjdk.org Mon Oct 13 13:46:51 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 13:46:51 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 13:17:37 GMT, Maurizio Cimadamore 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. > > src/java.base/share/classes/java/util/LazyCollections.java line 360: > >> 358: >> 359: @Stable >> 360: private final Set keySet; > > I believe putting the field in here might cause some redundancies -- for instance LazyMap extends this class and addss a `Map`, from which you can clearly derive the key set... It is true that `AbstractMap` already contains a `keySet` field. If we annotate `AbstractMap.keySet` with `@Stable` (which seems ok to do), we can get rid of this field. A note here is that eventually, we would like to get rid of all the fields in `AbstractMap`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426399337 From mcimadamore at openjdk.org Mon Oct 13 13:50:07 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Oct 2025 13:50:07 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg 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. src/java.base/share/classes/java/lang/LazyConstant.java line 276: > 274: * this method might block or throw. > 275: * > 276: * @implSpec The order of potential initialization triggering is specified as: Do we really need to specify this? src/java.base/share/classes/java/lang/LazyConstant.java line 312: > 310: String toString(); > 311: > 312: // Factories Suggestion: // Factory ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426409576 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426412926 From pminborg at openjdk.org Mon Oct 13 13:54:44 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 13:54:44 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v2] In-Reply-To: References: Message-ID: <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@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: Remove redundant field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/3e287031..0978179a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=00-01 Stats: 7 lines in 2 files changed: 3 ins; 3 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 pminborg at openjdk.org Mon Oct 13 14:03:37 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 14:03:37 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v3] In-Reply-To: References: Message-ID: > 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 links around Error and Throwable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/0978179a..5770e033 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 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 Oct 13 14:03:41 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 14:03:41 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v3] In-Reply-To: References: Message-ID: <0kU7XwB4vVkXnZLTj79Gen7puX7sPTKNfZwkf3I1wpM=.840e45e2-87bb-41ad-a4be-8d474458559d@github.com> On Mon, 13 Oct 2025 13:36:19 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/LazyConstant.java line 157: >> >>> 155: * The computing function runs on the caller?s thread. >>> 156: *

>>> 157: * If a thread that is blocked by another computing thread is interrupted, this is not >> >> I'm not sure I understand what you mean in this para > > E.g. "thread that is blocked by another computing thread". Did you mean to say "if the thread running the computing function is interrupted"? If a thread `A` won the race and invokes the computing function, and another thread `B` comes along while computation takes place by `A`, then interrupting thread `B` will not have any effect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426445641 From pminborg at openjdk.org Mon Oct 13 14:13:42 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 14:13:42 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v4] In-Reply-To: References: Message-ID: > 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: Reprhase text around the computing thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/5770e033..47af4307 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=02-03 Stats: 13 lines in 1 file changed: 1 ins; 2 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 pminborg at openjdk.org Mon Oct 13 14:18:53 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 14:18:53 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v5] In-Reply-To: References: Message-ID: > 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: Rephrase trusted field text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/47af4307..ea14b8f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=03-04 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 Oct 13 14:22:13 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 14:22:13 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v6] In-Reply-To: References: Message-ID: <5EAP5ubicOh_odm_aPlWJZbDQTuV0AIRs-fHlW7jTlc=.86692372-8a21-49dc-a453-4dbeef84d242@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: Define constant folding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/ea14b8f9..e25eeb9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=04-05 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 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 Oct 13 14:33:06 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 14:33:06 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v7] In-Reply-To: References: Message-ID: > 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: Update src/java.base/share/classes/java/lang/LazyConstant.java Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/e25eeb9b..5845a7a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=05-06 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 mcimadamore at openjdk.org Mon Oct 13 14:33:08 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Oct 2025 14:33:08 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v6] In-Reply-To: <5EAP5ubicOh_odm_aPlWJZbDQTuV0AIRs-fHlW7jTlc=.86692372-8a21-49dc-a453-4dbeef84d242@github.com> References: <5EAP5ubicOh_odm_aPlWJZbDQTuV0AIRs-fHlW7jTlc=.86692372-8a21-49dc-a453-4dbeef84d242@github.com> Message-ID: On Mon, 13 Oct 2025 14:22:13 GMT, Per Minborg 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: > > Define constant folding src/java.base/share/classes/java/lang/LazyConstant.java line 156: > 154: * {@code final} fields of any newly created objects, are safely published. > 155: *

> 156: * If the computing thread or any thread that is blocked by the computing thread My worry here is that when we say "any thread that is blocked" we really meany "any thread". But in reality this javadoc only refers to threads that are trying to call `get` and end up blocked because some other thread won the race. E.g. if a thread is blocked by the computing thread for any other reason, we don't know whether interrupting that thread will result in an `InterruptedException` ? I think it might be worth simplifying this a bit, starting with the property you want to assert: > Thread interruption does not cancel initialization of a lazy constant. In other words, if the computing thread is > interrupted, `LazyConstant::get` doesn't clear the interrupted thread?s status is not cleared, nor does it throw > an `InterruptedException`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426515394 From pminborg at openjdk.org Mon Oct 13 14:33:10 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Oct 2025 14:33:10 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v7] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 13:44:07 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/LazyConstant.java >> >> Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> > > src/java.base/share/classes/java/lang/LazyConstant.java line 192: > >> 190: * The {@code LazyConstant} type is not {@link Serializable}. >> 191: *

>> 192: * It is not recommended putting lazy constants into equality-based collections > > Not sure what you mean here. It seems like the javadoc for `equals` says that it triggers initialization, so it should be ok? Formally, it is ok, but may result in strange side effects if we, for example, put a key of type LazyConstant in a map. It will then be initialized immediately (upon `map.put()`), and the put operation can therefore have non-obvious side effects. > src/java.base/share/classes/java/lang/LazyConstant.java line 276: > >> 274: * this method might block or throw. >> 275: * >> 276: * @implSpec The order of potential initialization triggering is specified as: > > Do we really need to specify this? This is a corner case, but we might have two uninitialized LCs. The order in which they get computed might be significant (e.g., they operate on shared data structures). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426507366 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426513556 From mcimadamore at openjdk.org Mon Oct 13 14:33:13 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Oct 2025 14:33:13 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v7] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 14:25:58 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/lang/LazyConstant.java line 276: >> >>> 274: * this method might block or throw. >>> 275: * >>> 276: * @implSpec The order of potential initialization triggering is specified as: >> >> Do we really need to specify this? > > This is a corner case, but we might have two uninitialized LCs. The order in which they get computed might be significant (e.g., they operate on shared data structures). I understand that the order might be significant -- but I still wonder if we should specify that order. This seems to add constraints to the implementation. Do we really want clients to rely on the order in which lazy constants are initialized when calling `equals` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426522315 From mcimadamore at openjdk.org Mon Oct 13 14:37:27 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Oct 2025 14:37:27 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v7] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 14:23:40 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/lang/LazyConstant.java line 192: >> >>> 190: * The {@code LazyConstant} type is not {@link Serializable}. >>> 191: *

>>> 192: * It is not recommended putting lazy constants into equality-based collections >> >> Not sure what you mean here. It seems like the javadoc for `equals` says that it triggers initialization, so it should be ok? > > Formally, it is ok, but may result in strange side effects if we, for example, put a key of type LazyConstant in a map. It will then be initialized immediately (upon `map.put()`), and the put operation can therefore have non-obvious side effects. I think it would be better to link to `equals` more explicitly -- e.g. "As equals and hashCode might trigger the initialization of a lazy constant, it is recommended to avoid storing lazy constants into equality-based collections (or similar constructs) as their addition (e.g. via `Map::put`, or `Set::add`) might result in subtle side-effects). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426535831 From mcimadamore at openjdk.org Mon Oct 13 14:44:09 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Oct 2025 14:44:09 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v7] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 14:33:06 GMT, Per Minborg 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: > > Update src/java.base/share/classes/java/lang/LazyConstant.java > > Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> src/java.base/share/classes/java/lang/LazyConstant.java line 287: > 285: */ > 286: @Override > 287: boolean equals(Object obj); There is a tension here (same for hashCode). A lazy constant is a mutable cell that can be updated only once, given some computing function. When you compare two lazy constants, you can either compare the mutable cell (e.g. the pointer to the memory location where the constant will be eventually stored), or you can compare the constants. Here, the javadoc decides to opt for comparing the constants -- but this might be problematic, as now `equals` can throw exceptions too (and/or result in blocking, as you say in the javadoc). So, I'm not too sure what's the best option here -- do we have an idea of how frequent it is to want to compare two lazy constants "by value" ? (for reference, we have no precedent for this: `ClassValue`, `ScopedValue` and `ThreadLocal` do not redefine equals/hashCode). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426553275 From bpb at openjdk.org Mon Oct 13 16:07:09 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 16:07:09 GMT Subject: Integrated: 8368098: (aio) java/nio/channels/Channels/AsyncCloseStreams.java fails in junit timeout In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 16:31:38 GMT, Brian Burkhalter wrote: > In `AsyncCloseStreams.write`, write 100,000 bytes in each loop iteration instead of just one, the intent being to decrease the number of iterations. This pull request has now been integrated. Changeset: 8b1cf8ee Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/8b1cf8eefe4e3439dba983bced06d55a6ca7da4e Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8368098: (aio) java/nio/channels/Channels/AsyncCloseStreams.java fails in junit timeout Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/27750 From bpb at openjdk.org Mon Oct 13 16:08:00 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 16:08:00 GMT Subject: RFR: 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) In-Reply-To: <-UugMOoXhEOH0mVwQuqRTWGDUxyon3-oyQW9i8KaMDE=.124dac58-1846-465c-9005-cc96b27477cf@github.com> References: <-UugMOoXhEOH0mVwQuqRTWGDUxyon3-oyQW9i8KaMDE=.124dac58-1846-465c-9005-cc96b27477cf@github.com> Message-ID: <06bvg12tYrKtKxSmGcQ5kygBg20JarycBZl0qi21jns=.608a4b9c-fac8-435e-98ec-49f735828261@github.com> On Sat, 11 Oct 2025 06:29:21 GMT, Alan Bateman wrote: > Need to delete the stray file #UnixPath.java#? that has sneaked into your branch :-) Emacs messed me up. > You can use a switch expression here to `return` [...]. Cool. I was unaware of that. Will change. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27753#issuecomment-3398128393 PR Review Comment: https://git.openjdk.org/jdk/pull/27753#discussion_r2426758278 From bpb at openjdk.org Mon Oct 13 16:09:02 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 16:09:02 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS [v2] In-Reply-To: References: Message-ID: On Sat, 11 Oct 2025 06:41:41 GMT, Alan Bateman wrote: > Can you try a version that doesn't collect but instead opens a new UnixDirectoryStream for the second/slow scan? I was not sure of that either. I'll change it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2426761519 From duke at openjdk.org Mon Oct 13 16:52:00 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 13 Oct 2025 16:52:00 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v2] In-Reply-To: <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com> References: <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com> Message-ID: On Mon, 13 Oct 2025 13:54:44 GMT, Per Minborg 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: > > Remove redundant field src/java.base/share/classes/java/util/AbstractMap.java line 335: > 333: */ > 334: @Stable > 335: transient Set keySet; Are?all?uses of?this?field in?`java.util` able?to?handle the?`@Stable`ness of?this?field correctly? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426844190 From bpb at openjdk.org Mon Oct 13 17:55:22 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 17:55:22 GMT Subject: RFR: 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) [v2] In-Reply-To: References: Message-ID: > Map Windows error codes ERROR_NETWORK_ACCESS_DENIED and ERROR_PRIVILEGE_NOT_HELD to `java.nio.file.AccessDeniedException`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8368907: Return switch; remove stray file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27753/files - new: https://git.openjdk.org/jdk/pull/27753/files/7b834449..49e05eb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27753&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27753&range=00-01 Stats: 1046 lines in 2 files changed: 0 ins; 1039 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27753.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27753/head:pull/27753 PR: https://git.openjdk.org/jdk/pull/27753 From bpb at openjdk.org Mon Oct 13 17:55:23 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 17:55:23 GMT Subject: RFR: 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) In-Reply-To: <06bvg12tYrKtKxSmGcQ5kygBg20JarycBZl0qi21jns=.608a4b9c-fac8-435e-98ec-49f735828261@github.com> References: <-UugMOoXhEOH0mVwQuqRTWGDUxyon3-oyQW9i8KaMDE=.124dac58-1846-465c-9005-cc96b27477cf@github.com> <06bvg12tYrKtKxSmGcQ5kygBg20JarycBZl0qi21jns=.608a4b9c-fac8-435e-98ec-49f735828261@github.com> Message-ID: On Mon, 13 Oct 2025 16:04:23 GMT, Brian Burkhalter wrote: > Need to delete the stray file #UnixPath.java# Removed in 49e05eb. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27753#issuecomment-3398514506 From bpb at openjdk.org Mon Oct 13 17:55:26 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 17:55:26 GMT Subject: RFR: 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) [v2] In-Reply-To: <06bvg12tYrKtKxSmGcQ5kygBg20JarycBZl0qi21jns=.608a4b9c-fac8-435e-98ec-49f735828261@github.com> References: <-UugMOoXhEOH0mVwQuqRTWGDUxyon3-oyQW9i8KaMDE=.124dac58-1846-465c-9005-cc96b27477cf@github.com> <06bvg12tYrKtKxSmGcQ5kygBg20JarycBZl0qi21jns=.608a4b9c-fac8-435e-98ec-49f735828261@github.com> Message-ID: <99pK19auDHSvidnahRMxlf9235x6I82_k6YZ0ooyx7k=.1ea045d6-9618-4bdc-9e46-b79ab1dfb22b@github.com> On Mon, 13 Oct 2025 16:05:12 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsException.java line 81: >> >>> 79: IOException ex; >>> 80: >>> 81: switch (lastError()) { >> >> You can use a switch expression here to `return switch(lastError()) {`, no need for `ex`. > >> You can use a switch expression here to `return` [...]. > > Cool. I was unaware of that. Will change. Thanks. So changed in 49e05eb. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27753#discussion_r2426977603 From bpb at openjdk.org Mon Oct 13 22:33:25 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 22:33:25 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS [v3] In-Reply-To: References: Message-ID: > Try to avoid checking file keys for all entries by first attempting `Path.compareTo` and `String.equalsIgnoreCase`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8368633: Compare keys using a second DirectoryStream; improve micro ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27709/files - new: https://git.openjdk.org/jdk/pull/27709/files/5412b625..88b33417 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27709&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27709&range=01-02 Stats: 98 lines in 2 files changed: 79 ins; 8 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27709.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27709/head:pull/27709 PR: https://git.openjdk.org/jdk/pull/27709 From bpb at openjdk.org Mon Oct 13 22:33:26 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 22:33:26 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS [v2] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 16:06:39 GMT, Brian Burkhalter wrote: >> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 959: >> >>> 957: try (DirectoryStream entries = new UnixDirectoryStream(path, dp, filter)) { >>> 958: // compare path bytes until a match is found >>> 959: List notMatched = new ArrayList(); >> >> Can you try a version that doesn't collect but instead opens a new UnixDirectoryStream for the second/slow scan? I'm asking because the directory have many thousands of entries so there is a risk of OOME here. > >> Can you try a version that doesn't collect but instead opens a new UnixDirectoryStream for the second/slow scan? > > I was not sure of that either. I'll change it. So changed in 88b3341. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2427436218 From bpb at openjdk.org Mon Oct 13 22:33:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 22:33:28 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS [v2] In-Reply-To: References: Message-ID: On Sat, 11 Oct 2025 06:53:40 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8368633: Compare byte representations first then file keys; add micro > > test/micro/org/openjdk/bench/java/nio/file/ToRealPath.java line 52: > >> 50: files[i] = p; >> 51: } >> 52: } > > You can use `@TearDown` to remove the files. > > I think we'll need the benchmark to exercise some longer paths. Also I think it will have to exercise case sensitive, in this case the benchmark invokes toRealPath on "rEALpATH". That should give you a couple of scenarios that exercise both the first and second iterations. Improved in 88b3341. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2427436318 From bpb at openjdk.org Mon Oct 13 23:18:02 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Oct 2025 23:18:02 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS [v3] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 22:33:25 GMT, Brian Burkhalter wrote: >> Try to avoid checking file keys for all entries by first attempting `Path.compareTo` and `String.equalsIgnoreCase`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368633: Compare keys using a second DirectoryStream; improve micro Sample results from updated benchmark: Benchmark Mode Cnt Score Error Units ToRealPath.noFollowLinks thrpt 5 1434.226 ? 9.299 ops/s (master) ToRealPath.noFollowLinks thrpt 5 2854.991 ? 33.381 ops/s (commit 88b3341) The proposed change appears in this instance about twice as fast as the mainline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27709#issuecomment-3399366871 From swen at openjdk.org Tue Oct 14 00:54:03 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 14 Oct 2025 00:54:03 GMT Subject: RFR: 8362637: Convert java.nio.ByteOrder to an enum In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 18:21:26 GMT, Roger Riggs wrote: > Convert java.nio.ByteOrder to an enum. > The class declaration is changed from `public class` to `public enum`. > Enums are `Comparable` so declare LITTLE_ENDIAN before BIG_ENDIAN so LITTLE_ENDIAN is less than BIG_ENDIAN. > The implementation is simplified, removing the constructor and explicit static fields. > Remove the override of `toString`; the javadoc provided by Enum is sufficient. > > No changes to other classes or implementations are needed to pass Tier 1-3. getIntB/getIntL/putIntB/putIntL/getLongB/getLongL/putLongL/getLongL If the optimizer can handle it, these methods should be provided in ByteOrder ------------- PR Comment: https://git.openjdk.org/jdk/pull/27657#issuecomment-3399561637 From alanb at openjdk.org Tue Oct 14 06:10:18 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Oct 2025 06:10:18 GMT Subject: RFR: 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) [v2] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 17:55:22 GMT, Brian Burkhalter wrote: >> Map Windows error codes ERROR_NETWORK_ACCESS_DENIED and ERROR_PRIVILEGE_NOT_HELD to `java.nio.file.AccessDeniedException`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368907: Return switch; remove stray file Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27753#pullrequestreview-3334029410 From alanb at openjdk.org Tue Oct 14 06:37:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Oct 2025 06:37:03 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS [v3] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 22:33:25 GMT, Brian Burkhalter wrote: >> Try to avoid checking file keys for all entries by first attempting `Path.compareTo` and `String.equalsIgnoreCase`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368633: Compare keys using a second DirectoryStream; improve micro src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 988: > 986: break; > 987: } > 988: } catch (UnixException ignore) { I looked back at our discussion in JDK-8295753 (pr/10843) as to why we catch UnixException here and the concern was about access to file that is not in the path. If you have cycles, then I think it would be good to dig into that further so understand which cases can be ignored and not ignored. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2428057914 From alanb at openjdk.org Tue Oct 14 09:32:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Oct 2025 09:32:58 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS [v3] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 22:33:25 GMT, Brian Burkhalter wrote: >> Try to avoid checking file keys for all entries by first attempting `Path.compareTo` and `String.equalsIgnoreCase`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368633: Compare keys using a second DirectoryStream; improve micro So I think this version is okay. The catching of UnixException needs to be re-examined but it pre-dates the changes in this PR. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27709#pullrequestreview-3334709454 From dclarke at openjdk.org Tue Oct 14 10:07:43 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 14 Oct 2025 10:07:43 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> Message-ID: <2FqWU_ow8kYzfWsq5zVfZioxPKuDfAj1MD52YcWg4Bo=.9bbc3671-c16e-4d0a-8b75-99784e1449f6@github.com> On Thu, 28 Aug 2025 08:51:14 GMT, Darragh Clarke wrote: >> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. >> >> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. >> >> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. > > Darragh Clarke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - fixed copyright header > - merged master into branch > - moved repeating code into own method > - implementing feedback, adding missing errno checks, cleanup > - feedback > - general cleanup > - small refactoring > - Performance > - implementing feedback > - removed unrelated change > - ... and 2 more: https://git.openjdk.org/jdk/compare/ff9dd784...cc5f558a Closed as this ticket is being addressed in 2 other PRs, the first of which https://github.com/openjdk/jdk/pull/27590 is already integrated, and the second will be opened shortly and will be linked from here also ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3401061761 From dclarke at openjdk.org Tue Oct 14 10:07:45 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 14 Oct 2025 10:07:45 GMT Subject: Withdrawn: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote: > This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. > > These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. > > I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25546 From dclarke at openjdk.org Tue Oct 14 10:44:13 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 14 Oct 2025 10:44:13 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs Message-ID: This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. A brief rundown of the changes: - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value ------------- Commit messages: - cleanup - modify kqueue to use FFM, includes modifying previous jextract generated code Changes: https://git.openjdk.org/jdk/pull/27796/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27796&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360025 Stats: 856 lines in 18 files changed: 312 ins; 443 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/27796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27796/head:pull/27796 PR: https://git.openjdk.org/jdk/pull/27796 From pminborg at openjdk.org Tue Oct 14 10:56:04 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 14 Oct 2025 10:56:04 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:38:01 GMT, Darragh Clarke wrote: > This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. > > This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. > > A brief rundown of the changes: > - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` > - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes > - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 45: > 43: } > 44: > 45: static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.loaderLookup() Can we remove this static field? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2428727063 From pminborg at openjdk.org Tue Oct 14 11:00:49 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 14 Oct 2025 11:00:49 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:38:01 GMT, Darragh Clarke wrote: > This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. > > This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. > > A brief rundown of the changes: > - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` > - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes > - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 134: > 132: public static int kqueue() { > 133: try { > 134: return (int) kqueue.ADAPTED.invokeExact(); No tracing? src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 152: > 150: > 151: public static final MemorySegment ADDR = FFMUtils.findOrThrow("kevent"); > 152: public static final MethodHandle HANDLE = Linker.nativeLinker().downcallHandle(ADDR, DESC, I would suspect we do not use `ADDR` and `HANDLE` so maybe we do not have to store them? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2428738328 PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2428735537 From pminborg at openjdk.org Tue Oct 14 11:06:34 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 14 Oct 2025 11:06:34 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:38:01 GMT, Darragh Clarke wrote: > This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. > > This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. > > A brief rundown of the changes: > - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` > - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes > - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value src/java.base/macosx/classes/jdk/internal/ffi/util/FFMUtils.java line 39: > 37: public final class FFMUtils { > 38: > 39: public static final ValueLayout.OfBoolean C_BOOL = This class is specific for macOS but yet, it appears it would work for any platform (given its use of canonical layouts)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2428752099 From dclarke at openjdk.org Tue Oct 14 13:23:29 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 14 Oct 2025 13:23:29 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: <2Ah5xNoHK_HJ9ZpSvVYe_GS3XxyPy_sOjvWdDqnstGs=.4a748f03-c6ee-4808-a346-4c7fb8c0c7e5@github.com> On Tue, 14 Oct 2025 10:53:51 GMT, Per Minborg wrote: >> This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. >> >> This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. >> >> A brief rundown of the changes: >> - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` >> - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes >> - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value > > src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 45: > >> 43: } >> 44: >> 45: static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.loaderLookup() > > Can we remove this static field? You're right, i'll remove it > src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 152: > >> 150: >> 151: public static final MemorySegment ADDR = FFMUtils.findOrThrow("kevent"); >> 152: public static final MethodHandle HANDLE = Linker.nativeLinker().downcallHandle(ADDR, DESC, > > I would suspect we do not use `ADDR` and `HANDLE` so maybe we do not have to store them? The only place that uses them is `ADAPTED` directly below them, so it could get moved into that instead of being stored, though it might be a slight hit to readability. edit: I see theres also getters for them, though I don't think those are used anywhere > src/java.base/macosx/classes/jdk/internal/ffi/util/FFMUtils.java line 39: > >> 37: public final class FFMUtils { >> 38: >> 39: public static final ValueLayout.OfBoolean C_BOOL = > > This class is specific for macOS but yet, it appears it would work for any platform (given its use of canonical layouts)? Yeah I think with minimal changes (maybe none?) this could be moved to shared, though I don't know if we want to keep this current PR as minimal in scope as possible. I played it safe with just putting it in Mac for now but I'm happy for it to move ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2429140759 PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2429142232 PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2429157101 From dclarke at openjdk.org Tue Oct 14 13:44:06 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 14 Oct 2025 13:44:06 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:58:26 GMT, Per Minborg wrote: >> This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. >> >> This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. >> >> A brief rundown of the changes: >> - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` >> - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes >> - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value > > src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 134: > >> 132: public static int kqueue() { >> 133: try { >> 134: return (int) kqueue.ADAPTED.invokeExact(); > > No tracing? I can add something here, and to the other `ADAPTED ` call in the class ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2429246279 From bpb at openjdk.org Tue Oct 14 15:11:39 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 14 Oct 2025 15:11:39 GMT Subject: RFR: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS [v3] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 06:34:17 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8368633: Compare keys using a second DirectoryStream; improve micro > > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 988: > >> 986: break; >> 987: } >> 988: } catch (UnixException ignore) { > > I looked back at our discussion in JDK-8295753 (pr/10843) as to why we catch UnixException here and the concern was about access to file that is not in the path. If you have cycles, then I think it would be good to dig into that further so understand which cases can be ignored and not ignored. > The catching of UnixException needs to be re-examined but it pre-dates the changes in this PR. I will look into it in a sequel to this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27709#discussion_r2429547760 From bpb at openjdk.org Tue Oct 14 17:52:22 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 14 Oct 2025 17:52:22 GMT Subject: Integrated: 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 20:51:06 GMT, Brian Burkhalter wrote: > Map Windows error codes ERROR_NETWORK_ACCESS_DENIED and ERROR_PRIVILEGE_NOT_HELD to `java.nio.file.AccessDeniedException`. This pull request has now been integrated. Changeset: 65b8fe62 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/65b8fe62b4dc9355866df4b0ddd7cfccaaf0e39b Stats: 17 lines in 2 files changed: 2 ins; 0 del; 15 mod 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/27753 From bpb at openjdk.org Tue Oct 14 17:53:25 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 14 Oct 2025 17:53:25 GMT Subject: Integrated: 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 23:59:53 GMT, Brian Burkhalter wrote: > Try to avoid checking file keys for all entries by first attempting `Path.compareTo` and `String.equalsIgnoreCase`. This pull request has now been integrated. Changeset: 09e87971 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/09e87971e8a53951b40eef15d127aad0b7c2bee8 Stats: 181 lines in 3 files changed: 156 ins; 4 del; 21 mod 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/27709 From liach at openjdk.org Tue Oct 14 20:56:19 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 14 Oct 2025 20:56:19 GMT Subject: RFR: 8362637: Convert java.nio.ByteOrder to an enum In-Reply-To: References: Message-ID: <1MvaKRddjaNBEfVYRXOpuEQAcu43Cu3fhfCm5dvY7yg=.710820dc-7634-4389-9a80-c4766d92066f@github.com> On Mon, 6 Oct 2025 18:21:26 GMT, Roger Riggs wrote: > Convert java.nio.ByteOrder to an enum. > The class declaration is changed from `public class` to `public enum`. > Enums are `Comparable` so declare LITTLE_ENDIAN before BIG_ENDIAN so LITTLE_ENDIAN is less than BIG_ENDIAN. > The implementation is simplified, removing the constructor and explicit static fields. > Remove the override of `toString`; the javadoc provided by Enum is sufficient. > > No changes to other classes or implementations are needed to pass Tier 1-3. I think we will do that later. A lot of these operations are used in early bootstrap when we don't want to set up everything enums use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27657#issuecomment-3403579441 From duke at openjdk.org Wed Oct 15 05:27:15 2025 From: duke at openjdk.org (iseki) Date: Wed, 15 Oct 2025 05:27:15 GMT Subject: RFR: 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) [v2] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 17:55:22 GMT, Brian Burkhalter wrote: >> Map Windows error codes ERROR_NETWORK_ACCESS_DENIED and ERROR_PRIVILEGE_NOT_HELD to `java.nio.file.AccessDeniedException`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8368907: Return switch; remove stray file ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27753#issuecomment-3404571880 From aturbanov at openjdk.org Wed Oct 15 08:32:50 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 15 Oct 2025 08:32:50 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:38:01 GMT, Darragh Clarke wrote: > This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. > > This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. > > A brief rundown of the changes: > - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` > - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes > - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 154: > 152: public static final MethodHandle HANDLE = Linker.nativeLinker().downcallHandle(ADDR, DESC, > 153: Linker.Option.captureCallState(ERRNO_NAME)); > 154: public static final MethodHandle ADAPTED = CaptureStateUtil.adaptSystemCall(HANDLE, ERRNO_NAME); Suggestion: public static final MethodHandle ADAPTED = CaptureStateUtil.adaptSystemCall(HANDLE, ERRNO_NAME); src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 134: > 132: } > 133: > 134: static public int poll(int kqfd, MemorySegment pollAddress, int nevents, long timeout) { Let's use blessed modifiers order Suggestion: public static int poll(int kqfd, MemorySegment pollAddress, int nevents, long timeout) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2431609571 PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2431612250 From alanb at openjdk.org Wed Oct 15 08:52:33 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 15 Oct 2025 08:52:33 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: <6K5Nh56fqt2P-8hx8UzU40QDkWvhEao_LT_kQ7lPQA4=.7bc21735-6f2d-4edf-b35f-da46255cb851@github.com> On Wed, 15 Oct 2025 08:29:47 GMT, Andrey Turbanov wrote: >> This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. >> >> This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. >> >> A brief rundown of the changes: >> - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` >> - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes >> - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value > > src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 134: > >> 132: } >> 133: >> 134: static public int poll(int kqfd, MemorySegment pollAddress, int nevents, long timeout) { > > Let's use blessed modifiers order > Suggestion: > > public static int poll(int kqfd, MemorySegment pollAddress, int nevents, long timeout) { I assume "public" was added by mistake, this is not a public class, instead it's means to be a simpler wrapper on kqueue for the Selector, Port and Poller implementations in the macOS specific sun.nio.ch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2431679711 From alanb at openjdk.org Wed Oct 15 09:19:06 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 15 Oct 2025 09:19:06 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: <7-Gpaw-hqicNtRbyi_J58d4V6-95IY1EEJfocmdhIzU=.33959652-94cf-4e40-9f89-dfb6dc861148@github.com> On Tue, 14 Oct 2025 10:38:01 GMT, Darragh Clarke wrote: > This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. > > This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. > > A brief rundown of the changes: > - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` > - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes > - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java line 52: > 50: > 51: // address of the poll array passed to kqueue_wait > 52: private final MemorySegment pollArrayRegions; Can we drop "Regions" from the name? It's an array of kevent structures so pollArray will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2431789173 From alanb at openjdk.org Wed Oct 15 09:28:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 15 Oct 2025 09:28:44 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:38:01 GMT, Darragh Clarke wrote: > This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. > > This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. > > A brief rundown of the changes: > - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` > - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes > - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 99: > 97: */ > 98: static long getDescriptor(MemorySegment memoryHandle) { > 99: return kevent.ident(memoryHandle); Do you mind going back over the discussion we had in the original PR? The ident field is a 64-bit, an fd is an int. This means that KQueue should have a getDescriptor that returns an int, or a getIdent that returns a long. The former is cleaner at the use-sites. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27796#discussion_r2431823212 From bpb at openjdk.org Wed Oct 15 22:09:16 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 15 Oct 2025 22:09:16 GMT Subject: RFR: 8369854: (ch) Refine specification of behavior of {Gathering,Writable}ByteChannel.write Message-ID: Modify the specification of the `write` methods of `WritableByteChannel` and `GatheringByteChannel` in the `java.nio.channels` package to emphasize that each method invocation returns only the number of bytes written in that invocation and that `write` might have to be invoked more than once for all requested bytes to be written. ------------- Commit messages: - 8369854: (ch) Refine specification of behavior of {Gathering,Writable}ByteChannel.write Changes: https://git.openjdk.org/jdk/pull/27833/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27833&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369854 Stats: 16 lines in 2 files changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27833/head:pull/27833 PR: https://git.openjdk.org/jdk/pull/27833 From rriggs at openjdk.org Thu Oct 16 04:20:01 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 16 Oct 2025 04:20:01 GMT Subject: RFR: 8362637: Convert java.nio.ByteOrder to an enum In-Reply-To: References: Message-ID: <-avbqhCpCQMyki1lDSIxYuWJB4_L50aC0xhpBimhch4=.22f640c1-6a72-43d3-a987-f884dd4b86d6@github.com> On Mon, 6 Oct 2025 18:21:26 GMT, Roger Riggs wrote: > Convert java.nio.ByteOrder to an enum. > The class declaration is changed from `public class` to `public enum`. > Enums are `Comparable` so declare LITTLE_ENDIAN before BIG_ENDIAN so LITTLE_ENDIAN is less than BIG_ENDIAN. > The implementation is simplified, removing the constructor and explicit static fields. > Remove the override of `toString`; the javadoc provided by Enum is sufficient. > > No changes to other classes or implementations are needed to pass Tier 1-3. ByteOrder is just an enum, the get and set methods suggested belong elsewhere. The optimizer can do the right thing relative to the enum regardless of where they are implemented. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27657#issuecomment-3408160639 From rbkrbkrbkrbk7 at gmail.com Thu Oct 16 09:41:41 2025 From: rbkrbkrbkrbk7 at gmail.com (s rbk) Date: Thu, 16 Oct 2025 15:11:41 +0530 Subject: NIO and Platform Dependency Message-ID: Hi, Is NIO platform dependent. If there is no support for nonblocking I/O in underlying platform, does it fall back to blocking I/O -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Thu Oct 16 09:59:49 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 16 Oct 2025 10:59:49 +0100 Subject: NIO and Platform Dependency In-Reply-To: References: Message-ID: <2af1ee1d-5870-4d8e-aa3d-72d0b84130e9@oracle.com> On 16/10/2025 10:41, s rbk wrote: > Hi, > > Is NIO platform dependent. If there is no support for nonblocking I/O > in underlying platform, does it fall back to blocking I/O > I don't thin we've come across a platform that doesn't support non-blocking I/O. What is the context for your question? Is this a new port? -Alan From alanb at openjdk.org Thu Oct 16 11:17:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Oct 2025 11:17:14 GMT Subject: RFR: 8369854: (ch) Refine specification of behavior of {Gathering,Writable}ByteChannel.write In-Reply-To: References: Message-ID: <2X_1avdLUI1JiIKgspHtB-apsJlUqfuqfeid9bgqWQE=.75e7a535-d7f5-4d7c-ad8b-debad9b8e125@github.com> On Wed, 15 Oct 2025 22:01:12 GMT, Brian Burkhalter wrote: > Modify the specification of the `write` methods of `WritableByteChannel` and `GatheringByteChannel` in the `java.nio.channels` package to emphasize that each method invocation returns only the number of bytes written in that invocation and that `write` might have to be invoked more than once for all requested bytes to be written. src/java.base/share/classes/java/nio/channels/GatheringByteChannel.java line 87: > 85: * method returns the number of bytes written by its current invocation, > 86: * hence it might be necessary to call the write method in a loop until all > 87: * r bytes are written. The `@return` description also makes it clear that it returns the number of bytes written so I think we can drop "by its current invocation". I think it would be good if we could link to ByteBuffer::remaining or hasRemaining as this is the number of bytes that were not written. Maybe "It may be invoke write more than once to ensure that all remaining bytes are written"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27833#discussion_r2435514164 From pminborg at openjdk.org Thu Oct 16 12:10:32 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Oct 2025 12:10:32 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v7] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 14:41:11 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/LazyConstant.java >> >> Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> > > src/java.base/share/classes/java/lang/LazyConstant.java line 287: > >> 285: */ >> 286: @Override >> 287: boolean equals(Object obj); > > There is a tension here (same for hashCode). A lazy constant is a mutable cell that can be updated only once, given some computing function. When you compare two lazy constants, you can either compare the mutable cell (e.g. the pointer to the memory location where the constant will be eventually stored), or you can compare the constants. Here, the javadoc decides to opt for comparing the constants -- but this might be problematic, as now `equals` can throw exceptions too (and/or result in blocking, as you say in the javadoc). So, I'm not too sure what's the best option here -- do we have an idea of how frequent it is to want to compare two lazy constants "by value" ? > > (for reference, we have no precedent for this: `ClassValue`, `ScopedValue` and `ThreadLocal` do not redefine equals/hashCode). I have reverted back to the default Object::hashCode and Object::equals methods ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2435655625 From pminborg at openjdk.org Thu Oct 16 12:13:46 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Oct 2025 12:13:46 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v2] In-Reply-To: References: <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com> Message-ID: On Mon, 13 Oct 2025 16:48:07 GMT, ExE Boss wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant field > > src/java.base/share/classes/java/util/AbstractMap.java line 335: > >> 333: */ >> 334: @Stable >> 335: transient Set keySet; > > Are?all?uses of?this?field in?`java.util` able?to?handle the?`@Stable`ness of?this?field correctly? That is a good question. The potentially different keySet values should be freely substitutable or else there seams to be something wrong. If they are FS, then the VM should be able to pick any. But it is a big assumption to say that *all* maps that extend AM behave in such a way. We could go back to the previous version and shadow the field. That seems safest. Note: there is work in progress to remove these fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2435668562 From pminborg at openjdk.org Thu Oct 16 12:23:26 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Oct 2025 12:23:26 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v8] In-Reply-To: References: Message-ID: > 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 94 additional commits since the last revision: - Revert back to Object::(hashCode/equals) - Merge branch 'master' into lazy-constants - Update src/java.base/share/classes/java/lang/LazyConstant.java Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> - Define constant folding - Rephrase trusted field text - Reprhase text around the computing thread - Add links around Error and Throwable - Remove redundant field - Add optimization where the computing function is returned directly - Add benchmark of Optionals - ... and 84 more: https://git.openjdk.org/jdk/compare/6cbed094...8fa4a4ca ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/5845a7a5..8fa4a4ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=06-07 Stats: 10612 lines in 265 files changed: 5868 ins; 4190 del; 554 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 Thu Oct 16 12:33:31 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Oct 2025 12:33:31 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v9] In-Reply-To: References: Message-ID: > 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: Rephrase docs on interrupt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/8fa4a4ca..e6268f3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 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 Thu Oct 16 12:37:35 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Oct 2025 12:37:35 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v10] In-Reply-To: References: Message-ID: > 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: Update first javadoc sentence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/e6268f3d..f5493909 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 1 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 pminborg at openjdk.org Thu Oct 16 12:41:56 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Oct 2025 12:41:56 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v11] In-Reply-To: References: Message-ID: > 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 test descriptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/f5493909..a51f221a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=09-10 Stats: 2 lines in 2 files 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 rriggs at openjdk.org Thu Oct 16 15:57:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 16 Oct 2025 15:57:54 GMT Subject: Integrated: 8362637: Convert java.nio.ByteOrder to an enum In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 18:21:26 GMT, Roger Riggs wrote: > Convert java.nio.ByteOrder to an enum. > The class declaration is changed from `public class` to `public enum`. > Enums are `Comparable` so declare LITTLE_ENDIAN before BIG_ENDIAN so LITTLE_ENDIAN is less than BIG_ENDIAN. > The implementation is simplified, removing the constructor and explicit static fields. > Remove the override of `toString`; the javadoc provided by Enum is sufficient. > > No changes to other classes or implementations are needed to pass Tier 1-3. This pull request has now been integrated. Changeset: 95380e1e Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/95380e1ea5c3f531f82fb7c4b2f75726f3cd2fc2 Stats: 37 lines in 1 file changed: 5 ins; 28 del; 4 mod 8362637: Convert java.nio.ByteOrder to an enum Reviewed-by: alanb, liach, bpb ------------- PR: https://git.openjdk.org/jdk/pull/27657 From bpb at openjdk.org Thu Oct 16 18:19:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 16 Oct 2025 18:19:15 GMT Subject: RFR: 8369854: (ch) Refine specification of behavior of {Gathering,Writable}ByteChannel.write [v2] In-Reply-To: References: Message-ID: <3VDMwbhR-8MC_8LWVP0UpSPmd0QpM6lBvT_gzu7YQZ4=.e2682f81-1ce9-4b12-ba88-c857e5ad0d1d@github.com> > Modify the specification of the `write` methods of `WritableByteChannel` and `GatheringByteChannel` in the `java.nio.channels` package to emphasize that each method invocation returns only the number of bytes written in that invocation and that `write` might have to be invoked more than once for all requested bytes to be written. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8369854: Address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27833/files - new: https://git.openjdk.org/jdk/pull/27833/files/bb404a8f..c2da93a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27833&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27833&range=00-01 Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27833/head:pull/27833 PR: https://git.openjdk.org/jdk/pull/27833 From bpb at openjdk.org Thu Oct 16 18:19:17 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 16 Oct 2025 18:19:17 GMT Subject: RFR: 8369854: (ch) Refine specification of behavior of {Gathering,Writable}ByteChannel.write [v2] In-Reply-To: <2X_1avdLUI1JiIKgspHtB-apsJlUqfuqfeid9bgqWQE=.75e7a535-d7f5-4d7c-ad8b-debad9b8e125@github.com> References: <2X_1avdLUI1JiIKgspHtB-apsJlUqfuqfeid9bgqWQE=.75e7a535-d7f5-4d7c-ad8b-debad9b8e125@github.com> Message-ID: On Thu, 16 Oct 2025 11:14:33 GMT, Alan Bateman wrote: > The `@return` description [...]. Comments addressed in c2da93a. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27833#discussion_r2436997805 From alanb at openjdk.org Thu Oct 16 18:29:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Oct 2025 18:29:48 GMT Subject: RFR: 8369854: (ch) Refine specification of behavior of {Gathering,Writable}ByteChannel.write [v2] In-Reply-To: <3VDMwbhR-8MC_8LWVP0UpSPmd0QpM6lBvT_gzu7YQZ4=.e2682f81-1ce9-4b12-ba88-c857e5ad0d1d@github.com> References: <3VDMwbhR-8MC_8LWVP0UpSPmd0QpM6lBvT_gzu7YQZ4=.e2682f81-1ce9-4b12-ba88-c857e5ad0d1d@github.com> Message-ID: <66xUoEb542rGx9_XXNdbtDcD9IlGxIe-LYp8ove6Mpg=.11d198aa-b43d-4513-a8b8-4b901c584d1e@github.com> On Thu, 16 Oct 2025 18:19:15 GMT, Brian Burkhalter wrote: >> Modify the specification of the `write` methods of `WritableByteChannel` and `GatheringByteChannel` in the `java.nio.channels` package to emphasize that each method invocation returns only the number of bytes written in that invocation and that `write` might have to be invoked more than once for all requested bytes to be written. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8369854: Address reviewer comments Good ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27833#pullrequestreview-3346399903 From pminborg at openjdk.org Fri Oct 17 09:25:01 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 09:25:01 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v12] In-Reply-To: References: Message-ID: > 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: Update javadocs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/a51f221a..6a6e804e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=10-11 Stats: 59 lines in 1 file changed: 7 ins; 3 del; 49 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 Fri Oct 17 09:51:21 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 09:51:21 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg 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: > > Update javadocs src/java.base/share/classes/java/lang/LazyConstant.java line 46: > 44: * A lazy constant is created using the factory method > 45: * {@linkplain LazyConstant#of(Supplier) LazyConstant.of({@code })}. > 46: * When created, the contents (and hence the lazy constant itself) is not initialized. "When created, the lazy constant is not initialized, meaning it has no contents." E.g. it's the lazy constant that is initialized/not initialized. The content "just is". (or "is not", if not initialized). src/java.base/share/classes/java/lang/LazyConstant.java line 47: > 45: * {@linkplain LazyConstant#of(Supplier) LazyConstant.of({@code })}. > 46: * When created, the contents (and hence the lazy constant itself) is not initialized. > 47: * The contents (of type {@code T}) can then be initialized Again, "a lazy constant can be initialized, and its content retrieved, by calling get" src/java.base/share/classes/java/lang/LazyConstant.java line 50: > 48: * (and retrieved) by calling {@linkplain #get()}. The first time {@linkplain #get()} > 49: * is called, the underlying computing function (provided at construction) will > 50: * be invoked and the result will be used to initialize the contents. Once initialized, "and the result will be used to initialize the lazy constant. Once a lazy constant is initialized, its contents can never change..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439058429 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439060624 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439064085 From mcimadamore at openjdk.org Fri Oct 17 09:56:18 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 09:56:18 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg 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: > > Update javadocs src/java.base/share/classes/java/lang/LazyConstant.java line 54: > 52: * again upon subsequent {@linkplain #get() get} invocations. > 53: *

> 54: * A lazy constant is shallowly immutable, meaning the reference to the contents This para here seems a bit redundant. In part it repeats something already said (when initialized, contents will never change). I'd drop this from here, and maybe push it down to an API note (e.g. note: the contents of a lazy constant can be mutable -- e.g. an ArrayList). src/java.base/share/classes/java/lang/LazyConstant.java line 60: > 58: *

> 59: * Consider the following example where a lazy constant field "{@code logger}" is a > 60: * shallowly immutable holder of an object of type {@code Logger}: "where the lazy constant field "logger" holds an object of type Logger" src/java.base/share/classes/java/lang/LazyConstant.java line 77: > 75: *} > 76: *

> 77: * Initially, the lazy constant (and its contents) is not initialized. Suggestion: * Initially, the lazy constant is not initialized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439072055 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439073774 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439075865 From mcimadamore at openjdk.org Fri Oct 17 10:08:22 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 10:08:22 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg 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: > > Update javadocs src/java.base/share/classes/java/lang/LazyConstant.java line 101: > 99: * {@linkplain Error}, that {@linkplain Throwable} is propagated to the caller, and the > 100: * lazy constant remains uninitialized. In other words, upon an unsuccessful invocation of > 101: * the computing function, neither a constant, the exception, nor the fact that "In other words" I don't think this sentence adds much. I think it's better to just drop it. The main thing to say is that if computing function is unsuccessful, the lazy constant stays uninitialized (which we already said). src/java.base/share/classes/java/lang/LazyConstant.java line 111: > 109: * which are held by lazy constants: > 110: * > 111: * {@snippet lang = java: If you wanted, you could reuse the `Component` class -- that one already has a lazy constant field, so if you put the component itself in another lazy constant field you have your composition example. src/java.base/share/classes/java/lang/LazyConstant.java line 144: > 142: * > 143: *

Thread Safety

> 144: * A lazy constant is guaranteed to be initialized atomically and at most once. If We already mention some of these above: "Furthermore, {@linkplain #get()} guarantees that, out of several threads trying to * invoke the computing function simultaneously, only one is ever selected for * computation" Maybe add a reference form that text to this section? src/java.base/share/classes/java/lang/LazyConstant.java line 152: > 150: *

> 151: * The invocation of the computing function and the resulting initialization of > 152: * the constant {@linkplain java.util.concurrent##MemoryVisibility happens-before} Do you mean constant or content? I think the latter? E.g. when you initialize a lazy constant, you safely publish its contents? (the lazy constant itself is already published) src/java.base/share/classes/java/lang/LazyConstant.java line 158: > 156: * Thread interruption does not cancel the initialization of a lazy constant. In other > 157: * words, if the computing thread is interrupted, {@code LazyConstant::get} doesn't clear > 158: * the interrupted thread?s status, nor does it throw an InterruptedException. Suggestion: * the interrupted thread?s status, nor does it throw an {@code InterruptedException}. src/java.base/share/classes/java/lang/LazyConstant.java line 164: > 162: * > 163: *

Performance

> 164: * A lazy constant can never change after it has been initialized. Therefore, The contents of a lazy constant can never change after the lazy constant has been initialized (again, spell out things clearly) src/java.base/share/classes/java/lang/LazyConstant.java line 166: > 164: * A lazy constant can never change after it has been initialized. Therefore, > 165: * a JVM implementation may, for an initialized lazy constant, elide all future reads > 166: * of that lazy constant and instead directly use any constant that it has previously "elide all future reads of that lazy constant's contents and instead use the contents that has been previously observed" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439091644 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439096445 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439102301 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439110166 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439114804 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439119542 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439124386 From mcimadamore at openjdk.org Fri Oct 17 10:20:09 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 10:20:09 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v12] In-Reply-To: References:

Message-ID: <2V6nUv7mUoPV7kx6uQXMTM9D4Xdm-1xEK7ErgbEAdds=.0bc05925-08b5-4799-903c-04b9bfa4760d@github.com> On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg 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: > > Update javadocs src/java.base/share/classes/java/lang/LazyConstant.java line 168: > 166: * of that lazy constant and instead directly use any constant that it has previously > 167: * observed. We call this optimization constant folding. This is only possible if > 168: * the reference to the lazy constant is a VM constant (e.g. in cases where Not sure talking about VM constant is good. We could alternatively say: "if the lazy constant is stored in a static final field, either directly, or indirectly, via one or more trusted fields (i.e. any combination...)" src/java.base/share/classes/java/lang/LazyConstant.java line 179: > 177: * must be non-null, or a {@link NullPointerException} will be thrown. > 178: * > 179: * @apiNote Once a lazy constant is initialized with an object, the object cannot ever be Once a lazy constant is initialized, its contents can never be removed... src/java.base/share/classes/java/lang/LazyConstant.java line 182: > 180: * removed. This can be a source of an unintended memory leak. More specifically, > 181: * a lazy constant {@linkplain java.lang.ref##reachability strongly references} > 182: * the object it was initialized with. Hence, a lazy constant will hold s/the object it was initialized with/its contents (here and below) src/java.base/share/classes/java/lang/LazyConstant.java line 186: > 184: * is collected (if ever). > 185: *

> 186: * A {@code LazyConstant} that has a type parameter {@code T} that is an "A lazy constant whose contents is an array will not optimize access to the the elements of such array. Instead, ..." src/java.base/share/classes/java/lang/LazyConstant.java line 191: > 189: * Instead, a {@linkplain List#ofLazy(int, IntFunction) lazy list} of > 190: * arbitrary depth can be used, which provides constant components. > 191: * More generally, a lazy constant can hold other lazy constants of More generally... you said that in the composition section? src/java.base/share/classes/java/lang/LazyConstant.java line 233: > 231: > 232: /** > 233: * {@return the initialized contents. If not initialized, first computes and "initialized contents" is not a term you have defined in this javadoc. `get` returns the contents of this lazy constant. If the lazy constant is not initialized... src/java.base/share/classes/java/lang/LazyConstant.java line 267: > 265: */ > 266: @Override > 267: String toString(); I think it might be worth also defining a javadoc for equals/hashCode, to say explicitly that they will also not trigger initialization src/java.base/share/classes/java/lang/LazyConstant.java line 284: > 282: * directly. > 283: * > 284: * @param computingFunction in the form of a Supplier to be used to compute Suggestion: * @param computingFunction a {@code Supplier} used to initialize ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439138229 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439141653 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439144255 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439156012 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439150170 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439161143 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439169909 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439174349 From mcimadamore at openjdk.org Fri Oct 17 10:25:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 10:25:47 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg 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: > > Update javadocs src/java.base/share/classes/java/util/List.java line 1231: > 1229: * will be thrown. > 1230: *

> 1231: * The returned lazy list strongly references its computing We should say that hashCode/equals trigger computation src/java.base/share/classes/java/util/Map.java line 1784: > 1782: * will be thrown. > 1783: *

> 1784: * The returned lazy map strongly references its underlying Again, we should say that equals/hashCode triggers computation ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439200027 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439207782 From pminborg at openjdk.org Fri Oct 17 11:43:47 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 11:43:47 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v13] In-Reply-To: References: Message-ID: > 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: Update wording on List/Map Object methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/6a6e804e..8cde6974 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=11-12 Stats: 12 lines in 2 files changed: 12 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 pminborg at openjdk.org Fri Oct 17 12:13:48 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 12:13:48 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v14] In-Reply-To: References: Message-ID: > 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: Improve equals/hashCode document ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/8cde6974..77ae3fe1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=12-13 Stats: 19 lines in 1 file changed: 16 ins; 0 del; 3 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 Fri Oct 17 12:28:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 12:28:15 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v15] In-Reply-To: References: Message-ID: > 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: Improve method docs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/77ae3fe1..e2c24f5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=13-14 Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 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 Fri Oct 17 13:13:45 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 13:13:45 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v16] In-Reply-To: References: Message-ID: > 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: Update docs after comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/e2c24f5c..d961426d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=14-15 Stats: 58 lines in 1 file changed: 3 ins; 16 del; 39 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 Fri Oct 17 14:06:44 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 14:06:44 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v17] In-Reply-To: References: Message-ID: > 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: Revert the AbstractMap.keySet @Stable annotation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/d961426d..698b4125 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=15-16 Stats: 5 lines in 2 files changed: 4 ins; 1 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 pminborg at openjdk.org Fri Oct 17 14:10:39 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 14:10:39 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v2] In-Reply-To: References: <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com> Message-ID: On Thu, 16 Oct 2025 12:10:51 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/util/AbstractMap.java line 335: >> >>> 333: */ >>> 334: @Stable >>> 335: transient Set keySet; >> >> Are?all?uses of?this?field in?`java.util` able?to?handle the?`@Stable`ness of?this?field correctly? > > That is a good question. The potentially different keySet values should be freely substitutable or else there seams to be something wrong. If they are FS, then the VM should be able to pick any. But it is a big assumption to say that *all* maps that extend AM behave in such a way. We could go back to the previous version and shadow the field. That seems safest. > > Note: there is work in progress to remove these fields. I've reverted the @Stable annotation on AM.keySet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440164233 From mcimadamore at openjdk.org Fri Oct 17 14:17:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 14:17:54 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v16] In-Reply-To: References: Message-ID: <_kXdqyWalfyZNF_Bhnuw9NQh-9x3cutCQEB-r72fLR4=.aaadf47e-46d7-43d2-99dc-c6e0da1f8ad6@github.com> On Fri, 17 Oct 2025 13:13:45 GMT, Per Minborg 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: > > Update docs after comments src/java.base/share/classes/java/lang/LazyConstant.java line 154: > 152: * > 153: *

Performance

> 154: * The contents of lazy constant can never change after it has been initialized. Therefore, Suggestion: * The contents of a lazy constant can never change after it has been initialized. Therefore, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440185045 From mcimadamore at openjdk.org Fri Oct 17 14:30:06 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 14:30:06 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v16] In-Reply-To: References:

Message-ID: On Fri, 17 Oct 2025 14:23:28 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update docs after comments > > src/java.base/share/classes/java/util/List.java line 1235: > >> 1233: * or more lazy elements. The returned list's {@linkplain Object#toString() toString()} >> 1234: * method never triggers initialization of elements. Instead, an >> 1235: * implementation-dependant string is returned for uninitialized elements. > > Suggestion: > > * implementation-dependent string is returned for uninitialized elements. Design comment: I note some internal discomfort at the fact that equals/hashCode trigger initialization, but toString does not... effectively this would make replacing a regular immutable list with a lazy list not possible in all cases. Not saying we should do anything now -- but something to monitor ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440214527 From mcimadamore at openjdk.org Fri Oct 17 14:30:05 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 14:30:05 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v16] In-Reply-To: References:

Message-ID: On Fri, 17 Oct 2025 13:13:45 GMT, Per Minborg 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: > > Update docs after comments src/java.base/share/classes/java/lang/LazyConstant.java line 157: > 155: * a JVM implementation may, for an initialized lazy constant, elide all future reads of > 156: * that lazy constant's contents and instead use the contents that has been previously > 157: * observed. We call this optimization constant folding. This is only possible This is still not ok. First, there seems to be some typo ("if the reference to the lazy constant in a static final field or..."). Secondly, trusted chain _to_ such field. I think it's the other way around, the trusted chain starts at a static final field, and then eventually gets to the lazy constant, possibly traversing one or more trusted fields. src/java.base/share/classes/java/lang/LazyConstant.java line 174: > 172: * the lazy constant itself is collected (if ever). > 173: *

> 174: * A lazy constant whose contents is an array will not optimize access to "While it's possible to store an array inside a lazy constant, doing so will not result in improved access to the array elements. Instead ..." src/java.base/share/classes/java/lang/LazyConstant.java line 289: > 287: * > 288: * @param computingFunction in the form of a {@linkplain Supplier} to be used > 289: * to compute the constant s/compute/initialize (e.g. the term "compute the constant" is not defined anywhere) src/java.base/share/classes/java/util/List.java line 1235: > 1233: * or more lazy elements. The returned list's {@linkplain Object#toString() toString()} > 1234: * method never triggers initialization of elements. Instead, an > 1235: * implementation-dependant string is returned for uninitialized elements. Suggestion: * implementation-dependent string is returned for uninitialized elements. src/java.base/share/classes/java/util/Map.java line 1788: > 1786: * or more lazy values. The returned maps's {@linkplain Object#toString() toString()} > 1787: * method never triggers initialization of values. Instead, an > 1788: * implementation-dependant string is returned for uninitialized values. Suggestion: * implementation-dependent string is returned for uninitialized values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440193622 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440203445 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440207743 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440209019 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440216157 From pminborg at openjdk.org Fri Oct 17 14:29:55 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 14:29:55 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v18] In-Reply-To: References: Message-ID: > 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 104 additional commits since the last revision: - 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 - Fix test descriptions - Update first javadoc sentence - Rephrase docs on interrupt - ... and 94 more: https://git.openjdk.org/jdk/compare/e2f6db0f...fc064e47 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/698b4125..fc064e47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=16-17 Stats: 8176 lines in 211 files changed: 4888 ins; 2457 del; 831 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 Fri Oct 17 14:58:44 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 17 Oct 2025 14:58:44 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v19] In-Reply-To: References: Message-ID: > 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: Update after doc comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/fc064e47..6721ca4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=17-18 Stats: 14 lines in 3 files changed: 1 ins; 0 del; 13 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 Fri Oct 17 19:58:08 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 17 Oct 2025 19:58:08 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v19] In-Reply-To: References: Message-ID: <2Ow8e38mfpHtFTbD5kUe4BKOaWACguUWAfKwerScgMg=.228371ce-d23d-4dc2-816c-ce80c7da7771@github.com> On Fri, 17 Oct 2025 14:58:44 GMT, Per Minborg 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: > > Update after doc comments src/java.base/share/classes/java/lang/LazyConstant.java line 161: > 159: * to a lazy constant or if there is a chain from a {@code static final} field -- via one > 160: * or more trusted fields (i.e., {@code static final} fields, > 161: * {@linkplain Record record} fields, lazy constants, lazy lists, lazy maps, lazy constants and lazy lists/maps are not themselves "trusted final fields" (at least not yet), so not sure they belong here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2441086058 From duke at openjdk.org Sat Oct 18 01:07:11 2025 From: duke at openjdk.org (ExE Boss) Date: Sat, 18 Oct 2025 01:07:11 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v19] In-Reply-To: <2Ow8e38mfpHtFTbD5kUe4BKOaWACguUWAfKwerScgMg=.228371ce-d23d-4dc2-816c-ce80c7da7771@github.com> References: <2Ow8e38mfpHtFTbD5kUe4BKOaWACguUWAfKwerScgMg=.228371ce-d23d-4dc2-816c-ce80c7da7771@github.com> Message-ID: <7R8km2ZfztfyDcrUvjd_5P85J7pBMsxAIY-tP76jnTc=.d4311603-0098-4f89-84b3-f073bec00a4d@github.com> On Fri, 17 Oct 2025 19:55:42 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after doc comments > > src/java.base/share/classes/java/lang/LazyConstant.java line 161: > >> 159: * to a lazy constant or if there is a chain from a {@code static final} field -- via one >> 160: * or more trusted fields (i.e., {@code static final} fields, >> 161: * {@linkplain Record record} fields, lazy constants, lazy lists, lazy maps, > > lazy constants and lazy lists/maps are not themselves "trusted final fields" (at least not yet), so not sure they belong here? The?`@Stable`?annotation makes?fields with?non?`null`?values into?trusted?fields when?the?class is?loaded by?a?platform class?loader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2441495949 From bpb at openjdk.org Mon Oct 20 15:29:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 20 Oct 2025 15:29:15 GMT Subject: Integrated: 8369854: (ch) Refine specification of behavior of {Gathering,Writable}ByteChannel.write In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 22:01:12 GMT, Brian Burkhalter wrote: > Modify the specification of the `write` methods of `WritableByteChannel` and `GatheringByteChannel` in the `java.nio.channels` package to emphasize that each method invocation returns only the number of bytes written in that invocation and that `write` might have to be invoked more than once for all requested bytes to be written. This pull request has now been integrated. Changeset: a1be2979 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/a1be29791156645fdcad69a4b7ab770a05f0fe0e Stats: 14 lines in 2 files changed: 6 ins; 0 del; 8 mod 8369854: (ch) Refine specification of behavior of {Gathering,Writable}ByteChannel.write Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/27833 From pminborg at openjdk.org Wed Oct 22 07:51:30 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 22 Oct 2025 07:51:30 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v19] In-Reply-To: <7R8km2ZfztfyDcrUvjd_5P85J7pBMsxAIY-tP76jnTc=.d4311603-0098-4f89-84b3-f073bec00a4d@github.com> References: <2Ow8e38mfpHtFTbD5kUe4BKOaWACguUWAfKwerScgMg=.228371ce-d23d-4dc2-816c-ce80c7da7771@github.com> <7R8km2ZfztfyDcrUvjd_5P85J7pBMsxAIY-tP76jnTc=.d4311603-0098-4f89-84b3-f073bec00a4d@github.com> Message-ID: On Sat, 18 Oct 2025 01:04:37 GMT, ExE Boss wrote: >> src/java.base/share/classes/java/lang/LazyConstant.java line 161: >> >>> 159: * to a lazy constant or if there is a chain from a {@code static final} field -- via one >>> 160: * or more trusted fields (i.e., {@code static final} fields, >>> 161: * {@linkplain Record record} fields, lazy constants, lazy lists, lazy maps, >> >> lazy constants and lazy lists/maps are not themselves "trusted final fields" (at least not yet), so not sure they belong here? > > The?`@Stable`?annotation makes?fields with?non?`null`?values into?trusted?fields when?the?class is?loaded by?a?platform class?loader. There could be a chain: `static final` -> record component -> lazy list element -> record component, for example, and this would be a trusted chain. There are other constucts that could be in the chain as well and that are not mentioned (e.g. a `List.of()`) so perhaps we should do some change here. Easiest is to just remove the mention of lazy*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2450745732 From pminborg at openjdk.org Fri Oct 24 08:51:06 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 24 Oct 2025 08:51:06 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v19] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 14:58:44 GMT, Per Minborg 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: > > Update after doc comments After some discussion, we have concluded that we need to rework how `toString()` works for `LazyConstant`, lazy maps, and lists: #### For `LazyConstant` In order to align with other comput-later constructs like `Future`, we'd like to provide something like this: java.lang.LazyConstant at 5ed828d[computing function = $Lambda/0x00000ffe000d6550 at 4d3167f4] // Uninitialized java.lang.LazyConstant at 4ad92aa[42] // Initialized #### For lazy list, map, and all their derivatives (e.g., `subList()`, `values()`) There is a tension between the willingness to keep the `toString()` methods lazy during debugging and the compatibility with the existing `List` and `Map` implementations. It would be very surprising if a lazy list would output something different from a normal list for `toString()`. We think it is more important that lazy constructs are compatible with their corresponding eager constructs. Hence, we propose to make `toString()` trigger initialization of all elements/values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3441894953 From pminborg at openjdk.org Fri Oct 24 09:01:10 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 24 Oct 2025 09:01:10 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v20] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27605/files - new: https://git.openjdk.org/jdk/pull/27605/files/6721ca4a..c3278e0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=18-19 Stats: 271 lines in 5 files changed: 27 ins; 211 del; 33 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 Sat Oct 25 02:53:01 2025 From: duke at openjdk.org (Josiah Noel) Date: Sat, 25 Oct 2025 02:53:01 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v13] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Update ExchangeImpl.java - Merge remote-tracking branch 'upstream/master' into JDK-8368695 - reduce diff - Merge remote-tracking branch 'upstream/master' into JDK-8368695 - Update SwitchingProtocolTest.java - Update SwitchingProtocolTest.java - Update SwitchingProtocolTest.java - add exception test - Create UpgradeOutputStream.java - close raw streams - ... and 8 more: https://git.openjdk.org/jdk/compare/32697bf6...ae2b1184 ------------- Changes: https://git.openjdk.org/jdk/pull/27751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=12 Stats: 25304 lines in 632 files changed: 6529 ins; 14641 del; 4134 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From duke at openjdk.org Sat Oct 25 02:53:02 2025 From: duke at openjdk.org (Josiah Noel) Date: Sat, 25 Oct 2025 02:53:02 GMT Subject: Withdrawn: 8368695: Support 101 switching protocol in jdk.httpserver In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 19:45:57 GMT, Josiah Noel wrote: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27751 From vyazici at openjdk.org Mon Oct 27 12:32:39 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 27 Oct 2025 12:32:39 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode Message-ID: [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 ------------- Commit messages: - Remove unused `sun.nio.cs.ArrayEncoder::encode` Changes: https://git.openjdk.org/jdk/pull/27999/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27999&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363925 Stats: 261 lines in 6 files changed: 64 ins; 179 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/27999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27999/head:pull/27999 PR: https://git.openjdk.org/jdk/pull/27999 From rriggs at openjdk.org Mon Oct 27 14:43:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 27 Oct 2025 14:43:59 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode In-Reply-To: References: Message-ID: <2NNRaDE6GVefZ55qD1IaLwfnIv_9BGyCTn6JYxFjvS4=.624d307c-1293-4ae5-8c57-31684a10ffde@github.com> On Mon, 27 Oct 2025 11:42:20 GMT, Volkan Yazici wrote: > [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. > > [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 > [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 test/jdk/sun/nio/cs/TestStringCoding.java line 295: > 293: return IntStream.range(0, bs.length) > 294: .mapToObj(i -> String.format("0x%02X", bs[i] & 0xFF)) > 295: .collect(Collectors.joining(", ", "[", "]")); fyi, java.util.HexFormat can do that too: Suggestion: return "[" + HexFormat.ofDelimiter(", ").withPrefix("0x").formatHex(bs) + "]"; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27999#discussion_r2465949995 From prappo at openjdk.org Mon Oct 27 17:51:36 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 27 Oct 2025 17:51:36 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently Message-ID: Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/27972/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370568 Stats: 207 lines in 77 files changed: 0 ins; 0 del; 207 mod Patch: https://git.openjdk.org/jdk/pull/27972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972 PR: https://git.openjdk.org/jdk/pull/27972 From vyazici at openjdk.org Mon Oct 27 19:44:41 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 27 Oct 2025 19:44:41 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode [v2] In-Reply-To: References: Message-ID: > [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. > > [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 > [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Use `HexFormat` Co-authored-by: Roger Riggs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27999/files - new: https://git.openjdk.org/jdk/pull/27999/files/ac07c09d..a8c471f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27999&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27999&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27999/head:pull/27999 PR: https://git.openjdk.org/jdk/pull/27999 From rriggs at openjdk.org Mon Oct 27 20:45:02 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 27 Oct 2025 20:45:02 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo wrote: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3385391439 From liach at openjdk.org Mon Oct 27 23:05:02 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Oct 2025 23:05:02 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode [v2] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 19:44:41 GMT, Volkan Yazici wrote: >> [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. >> >> [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 >> [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Use `HexFormat` > > Co-authored-by: Roger Riggs I recommend further refactors, at least turn the 3 default methods to abstract methods. After removal of ineffective CESU_8, we can make the default methods abstract to improve safety. Down the road, we can remove the -1 handling at use site, and also pass in dp explicitly (I recall this being useful for optimizing Writer/OutputStream) src/java.base/share/classes/sun/nio/cs/CESU_8.java line 1: > 1: /* The ArrayEncoder interface is now useless here. We should remove it. ------------- PR Review: https://git.openjdk.org/jdk/pull/27999#pullrequestreview-3385808944 PR Review Comment: https://git.openjdk.org/jdk/pull/27999#discussion_r2467352713 From alanb at openjdk.org Tue Oct 28 07:00:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 07:00:03 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo wrote: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1044: > 1042: * already cancelled. This interrupts the threads executing unfinished subtasks. This > 1043: * method then waits for all threads to finish. If interrupted while waiting then it > 1044: * will continue to wait until the threads finish, before completing with the interrupted Can you drop the change to this file from the PR as we have reworded this paragraph as part of the updated for JEP 525. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468133283 From alanb at openjdk.org Tue Oct 28 07:52:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 07:52:03 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo wrote: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. I skimmed through the replace and it looks okay. There are several places where we should be linking as "interrupted status" will look like a grammatical error with the change. We do that as needed, not this PR. This is the first update to some of these files in 2025 so you will need to update the copyright header of those files. src/java.base/share/classes/java/net/DatagramSocket.java line 614: > 612: * interrupting a thread receiving a datagram packet will close the > 613: * underlying channel and cause this method to throw {@link > 614: * java.nio.channels.ClosedByInterruptException} with the interrupted Can you change this to "the thread's interrupted status set"? src/java.base/share/classes/java/net/DatagramSocket.java line 620: > 618: * datagram packet. In that case, interrupting the virtual thread will > 619: * cause it to wakeup and close the socket. This method will then throw > 620: * {@code SocketException} with the interrupted status set. Same thing here, and in ServerSocket and Socket. test/jdk/java/lang/Thread/virtual/CustomScheduler.java line 207: > 205: > 206: /** > 207: * Test running task with the carrier interrupted status set. We can change this to "the carrier's interrupted status set". ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387081610 PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468253205 PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468257078 PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468273763 From vyazici at openjdk.org Tue Oct 28 08:47:31 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 28 Oct 2025 08:47:31 GMT Subject: RFR: 8366575: Remove SDP support Message-ID: 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 ------------- Commit messages: - Remove SDP support Changes: https://git.openjdk.org/jdk/pull/28012/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28012&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366575 Stats: 732 lines in 13 files changed: 0 ins; 732 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28012.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28012/head:pull/28012 PR: https://git.openjdk.org/jdk/pull/28012 From alanb at openjdk.org Tue Oct 28 09:01:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 09:01:01 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 The tests for this feature were removed by "JEP 381: Remove the Solaris and SPARC Ports" and I don't think there are any other tests to purge. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28012#issuecomment-3455289444 From vyazici at openjdk.org Tue Oct 28 09:37:58 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 28 Oct 2025 09:37:58 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode [v3] In-Reply-To: References: Message-ID: > [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. > > [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 > [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Remove `ArrayEncoder` defaults and add `dp` parameter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27999/files - new: https://git.openjdk.org/jdk/pull/27999/files/a8c471f2..c599d8d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27999&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27999&range=01-02 Stats: 34 lines in 8 files changed: 0 ins; 14 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27999/head:pull/27999 PR: https://git.openjdk.org/jdk/pull/27999 From alanb at openjdk.org Tue Oct 28 09:39:30 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 09:39:30 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: <5U-sTIq_Pd8cXyzMvVU45J_zq1eogB0pn6X4iYKnUa0=.52739b0e-4981-4bce-b2ec-cd4a8adbf3ae@github.com> On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28012#pullrequestreview-3387687382 From vyazici at openjdk.org Tue Oct 28 09:42:17 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 28 Oct 2025 09:42:17 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode [v4] In-Reply-To: References: Message-ID: <1LfvGeGuRb5HTipmLXl3WOu_f61eXjmWY0nl9Jw29uc=.42bf8be5-486b-4083-b3d9-6103dff1e314@github.com> > [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. > > [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 > [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 Volkan Yazici has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Remove `ArrayEncoder` defaults and add `dp` parameter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27999/files - new: https://git.openjdk.org/jdk/pull/27999/files/c599d8d3..7fc52675 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27999&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27999&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27999/head:pull/27999 PR: https://git.openjdk.org/jdk/pull/27999 From vyazici at openjdk.org Tue Oct 28 09:42:21 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 28 Oct 2025 09:42:21 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode [v2] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 22:59:07 GMT, Chen Liang wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Use `HexFormat` >> >> Co-authored-by: Roger Riggs > > src/java.base/share/classes/sun/nio/cs/CESU_8.java line 1: > >> 1: /* > > The ArrayEncoder interface is now useless here. We should remove it. Very sharp of you! ? Removed in 7fc526759bf. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27999#discussion_r2468746916 From vyazici at openjdk.org Tue Oct 28 09:46:30 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 28 Oct 2025 09:46:30 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode [v2] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 23:02:44 GMT, Chen Liang wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Use `HexFormat` >> >> Co-authored-by: Roger Riggs > > I recommend further refactors, at least turn the 3 default methods to abstract methods. After removal of ineffective CESU_8, we can make the default methods abstract to improve safety. > > Down the road, we can remove the -1 handling at use site, and also pass in dp explicitly (I recall this being useful for optimizing Writer/OutputStream) @liach, thanks so much for the review! ? > I recommend further refactors, at least turn the 3 default methods to abstract methods. > After removal of ineffective CESU_8, we can make the default methods abstract to improve safety. > Down the road, we can remove the -1 handling at use site, and also pass in dp explicitly All done in 7fc526759bf. > I recall this [passing `dp` explicitly] being useful for optimizing Writer/OutputStream Skimmed through `ArrayEncoder::encodeFrom*` call-sites, but could not spot anything particular that can quickly be addressed. Please let me know if there are any changes I can carry out within the scope of this JBS/PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27999#issuecomment-3455507136 From prappo at openjdk.org Tue Oct 28 10:06:36 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 28 Oct 2025 10:06:36 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v2] In-Reply-To: References: Message-ID: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision: - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d - Reword for clarity as suggested - Drop to ease upcoming merge from loom repo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27972/files - new: https://git.openjdk.org/jdk/pull/27972/files/a10f8b43..89dbafe0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=00-01 Stats: 67 lines in 47 files changed: 4 ins; 0 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/27972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972 PR: https://git.openjdk.org/jdk/pull/27972 From alanb at openjdk.org Tue Oct 28 10:10:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 10:10:11 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v2] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 10:06:36 GMT, Pavel Rappo wrote: >> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. >> >> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. > > Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision: > > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d > + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d > + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d > + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d > + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d > + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d > + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d > + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d > + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d > + update test/... Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387827557 From jpai at openjdk.org Tue Oct 28 10:26:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 28 Oct 2025 10:26:39 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code Message-ID: Can I please get a review of this change which removes an obsolete internal interface? The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. ------------- Commit messages: - 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code Changes: https://git.openjdk.org/jdk/pull/28016/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28016&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6400876 Stats: 66 lines in 2 files changed: 0 ins; 65 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28016/head:pull/28016 PR: https://git.openjdk.org/jdk/pull/28016 From djelinski at openjdk.org Tue Oct 28 10:38:02 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 28 Oct 2025 10:38:02 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 10:18:57 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes an obsolete internal interface? > > The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. > > tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. Nice cleanup! [This line](https://github.com/openjdk/jdk/blob/9625993611bb6acf84d428bea4a65d33b9d66e5f/test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java#L1065) should probably be removed. src/java.base/share/classes/jdk/internal/loader/Resource.java line 133: > 131: */ > 132: public ByteBuffer getByteBuffer() throws IOException { > 133: InputStream in = cachedInputStream(); The method documentation could use a cleanup as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/28016#pullrequestreview-3387970929 PR Review Comment: https://git.openjdk.org/jdk/pull/28016#discussion_r2468960413 From vyazici at openjdk.org Tue Oct 28 10:54:02 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 28 Oct 2025 10:54:02 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code In-Reply-To: References: Message-ID: <041h9tvSriFOhGd7EOYE5c629F5IogUuWlh9qKmQo6c=.641a531f-11ef-4562-b627-7cabd423cde1@github.com> On Tue, 28 Oct 2025 10:18:57 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes an obsolete internal interface? > > The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. > > tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. Nice clean up! Agreed with @djelinski that `Resource` docs could use a cleanup as well. Personally, I'd expect an empty `git grep ByteBuffered` output. Spotted another usage: https://github.com/openjdk/jdk/blob/9625993611bb6acf84d428bea4a65d33b9d66e5f/test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java#L1065 ------------- PR Review: https://git.openjdk.org/jdk/pull/28016#pullrequestreview-3388061046 From jpai at openjdk.org Tue Oct 28 11:00:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 28 Oct 2025 11:00:07 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code In-Reply-To: References: Message-ID: <4lzbErAUbAQNBhv7O7KM7sbUUa_VzsZW9rxyDGDq4F8=.9dc4764e-0bc4-454d-a495-058a937dca1e@github.com> On Tue, 28 Oct 2025 10:34:54 GMT, Daniel Jeli?ski wrote: > Nice cleanup! > > [This line](https://github.com/openjdk/jdk/blob/9625993611bb6acf84d428bea4a65d33b9d66e5f/test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java#L1065) should probably be removed. Good catch. I need to go back and check why my search didn't find this one. I'll update the PR shortly. > src/java.base/share/classes/jdk/internal/loader/Resource.java line 133: > >> 131: */ >> 132: public ByteBuffer getByteBuffer() throws IOException { >> 133: InputStream in = cachedInputStream(); > > The method documentation could use a cleanup as well. Hello Daniel, i did consider that too but decided not to change it because there are implementations of `Resource` class which override this method to indeed return a `ByteBuffer` for certain implementations. Of course in those implementations they don't use the obsolete `ByteBuffered` interface. The javadoc text appeared generic enough to leave it in the current form. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28016#issuecomment-3455873612 PR Review Comment: https://git.openjdk.org/jdk/pull/28016#discussion_r2469054578 From jpai at openjdk.org Tue Oct 28 13:05:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 28 Oct 2025 13:05:42 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code In-Reply-To: References: Message-ID: <7dBg1cvMzAwMDsOQzD01cfFzkvWlUQxdCQ0cOxtXqkQ=.b0fb8fe6-5d82-40c9-86db-b7f42b174647@github.com> On Tue, 28 Oct 2025 10:18:57 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes an obsolete internal interface? > > The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. > > tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. I have now updated the PR to remove the reference from the micro benchmark test and also run that micro benchmark to make sure it continues to pass. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28016#issuecomment-3456367011 From jpai at openjdk.org Tue Oct 28 13:05:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 28 Oct 2025 13:05:41 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which removes an obsolete internal interface? > > The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. > > tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: remove reference from ImageReaderBenchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28016/files - new: https://git.openjdk.org/jdk/pull/28016/files/8a37155f..511ffd97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28016&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28016&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28016/head:pull/28016 PR: https://git.openjdk.org/jdk/pull/28016 From liach at openjdk.org Tue Oct 28 14:03:24 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Oct 2025 14:03:24 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode [v4] In-Reply-To: <1LfvGeGuRb5HTipmLXl3WOu_f61eXjmWY0nl9Jw29uc=.42bf8be5-486b-4083-b3d9-6103dff1e314@github.com> References: <1LfvGeGuRb5HTipmLXl3WOu_f61eXjmWY0nl9Jw29uc=.42bf8be5-486b-4083-b3d9-6103dff1e314@github.com> Message-ID: On Tue, 28 Oct 2025 09:42:17 GMT, Volkan Yazici wrote: >> [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. >> >> [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 >> [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 > > Volkan Yazici has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Remove `ArrayEncoder` defaults and add `dp` parameter Thank you for this great cleanup. Looks much more maintainable and straightforward. We can re-implement for CESU_8 if there is request later. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27999#pullrequestreview-3388946460 From prappo at openjdk.org Tue Oct 28 14:25:06 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 28 Oct 2025 14:25:06 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v3] In-Reply-To: References: Message-ID: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'jdk/master' into 8370568 - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d - Reword for clarity as suggested - Drop to ease upcoming merge from loom repo - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27972/files - new: https://git.openjdk.org/jdk/pull/27972/files/89dbafe0..b3297337 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=01-02 Stats: 3639 lines in 160 files changed: 1891 ins; 1140 del; 608 mod Patch: https://git.openjdk.org/jdk/pull/27972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972 PR: https://git.openjdk.org/jdk/pull/27972 From djelinski at openjdk.org Tue Oct 28 14:39:59 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 28 Oct 2025 14:39:59 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code [v2] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 13:05:41 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes an obsolete internal interface? >> >> The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. >> >> tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove reference from ImageReaderBenchmark Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28016#pullrequestreview-3389137143 From alanb at openjdk.org Tue Oct 28 15:44:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 15:44:53 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and releated obsolete code [v2] In-Reply-To: References: Message-ID: <07G6u-Oq9_rjmJDywRqSQwpfwkrDzVyxeX4if6P4bM4=.824b9a6d-e3bb-4198-bca5-826ff27534a9@github.com> On Tue, 28 Oct 2025 13:05:41 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes an obsolete internal interface? >> >> The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. >> >> tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove reference from ImageReaderBenchmark Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28016#pullrequestreview-3389473215 From erikj at openjdk.org Tue Oct 28 19:20:22 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 28 Oct 2025 19:20:22 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28012#pullrequestreview-3390435914 From lmesnik at openjdk.org Tue Oct 28 23:38:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 28 Oct 2025 23:38:41 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory Message-ID: There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. The tests that are incompatible with test thread factory are marked with test.thread.factory == null and the tests that are rather incompatible with virtual threads are makred with test.thread.factory != "Virtual" ------------- Commit messages: - 8370851: Mark hotspot and jdk tests incompatible with test thread factory Changes: https://git.openjdk.org/jdk/pull/28030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370851 Stats: 32 lines in 14 files changed: 17 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/28030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28030/head:pull/28030 PR: https://git.openjdk.org/jdk/pull/28030 From bpb at openjdk.org Wed Oct 29 00:58:27 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 29 Oct 2025 00:58:27 GMT Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win) Message-ID: If `getFinalPath` throws an exception, or converts a drive path to a UNC path, then fall back to the slow path which uses `resolveAllLinks`. ------------- Commit messages: - 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win) Changes: https://git.openjdk.org/jdk/pull/28032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368165 Stats: 24 lines in 1 file changed: 18 ins; 0 del; 6 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 Oct 29 00:58:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 29 Oct 2025 00:58:28 GMT Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win) In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 00:52:18 GMT, Brian Burkhalter 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`. This change was tested successfully with links and files on a local mapped disk and on remote shares on macOS and Windows machines. It might be that falling back to the slow path should be limited to a certain subset of error codes encountered by `GetFinalPathNameByHandle` rather than falling back for all exceptions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28032#issuecomment-3459213129 From rriggs at openjdk.org Wed Oct 29 01:49:05 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 29 Oct 2025 01:49:05 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v3] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo wrote: >> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. >> >> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into 8370568 > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d > + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d > + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d > + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d > + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d > + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d > + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d > + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test... Nice cleanup. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3391422490 From alanb at openjdk.org Wed Oct 29 07:00:04 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 29 Oct 2025 07:00:04 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 28: > 26: * @bug 8284161 8303242 > 27: * @summary Test com.sun.management.ThreadMXBean with virtual threads > 28: * @requires test.thread.factory != "Virtual" This test allows the "main thread" to be a virtual thread so should pass with JTREG_TEST_THREAD_FACTORY=Virtual. Can you re-check your notes as to why this one should be excluded from JTREG_TEST_THREAD_FACTORY=Virtual runs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28030#discussion_r2471923090 From vyazici at openjdk.org Wed Oct 29 08:24:07 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 08:24:07 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and related obsolete code [v2] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 13:05:41 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes an obsolete internal interface? >> >> The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. >> >> tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove reference from ImageReaderBenchmark Marked as reviewed by vyazici (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28016#pullrequestreview-3392149950 From jpai at openjdk.org Wed Oct 29 08:59:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 08:59:07 GMT Subject: RFR: 6400876: (bf) Remove sun.nio.ByteBuffered and related obsolete code [v2] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 13:05:41 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes an obsolete internal interface? >> >> The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. >> >> tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove reference from ImageReaderBenchmark Thank you everyone for the reviews. tier1, tier2, tier3 testing passed without any related issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28016#issuecomment-3460437365 From jpai at openjdk.org Wed Oct 29 09:03:32 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 09:03:32 GMT Subject: Integrated: 6400876: (bf) Remove sun.nio.ByteBuffered and related obsolete code In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 10:18:57 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes an obsolete internal interface? > > The `sun.nio.ByteBuffered` interface is internal to the java.base module and does not have any implementations in the JDK. The only place where we use this is in `jdk.internal.loader.Resource` (another internal class within java.base). The usage itself is a mere `instanceof` check against the `InputStream` corresponding to that `Resource`. Given that there are no implementations of this interface, that check is redundant. > > tier testing is currently in progress with this change, and given the nature of this change, no new tests have been introduced. This pull request has now been integrated. Changeset: 20bcf0ed Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/20bcf0eddaee0a57142bcc614cc5415b53c16460 Stats: 67 lines in 3 files changed: 0 ins; 66 del; 1 mod 6400876: (bf) Remove sun.nio.ByteBuffered and related obsolete code Reviewed-by: djelinski, vyazici, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28016 From jpai at openjdk.org Wed Oct 29 09:42:22 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 09:42:22 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v3] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo wrote: >> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. >> >> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into 8370568 > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d > + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d > + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d > + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d > + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d > + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d > + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d > + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test... Hello Pavel, these changes look OK to me. Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392430217 From vyazici at openjdk.org Wed Oct 29 10:04:32 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 10:04:32 GMT Subject: RFR: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode [v4] In-Reply-To: <1LfvGeGuRb5HTipmLXl3WOu_f61eXjmWY0nl9Jw29uc=.42bf8be5-486b-4083-b3d9-6103dff1e314@github.com> References: <1LfvGeGuRb5HTipmLXl3WOu_f61eXjmWY0nl9Jw29uc=.42bf8be5-486b-4083-b3d9-6103dff1e314@github.com> Message-ID: On Tue, 28 Oct 2025 09:42:17 GMT, Volkan Yazici wrote: >> [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. >> >> [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 >> [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 > > Volkan Yazici has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Remove `ArrayEncoder` defaults and add `dp` parameter Tier1-2 is clear on 7fc526759bf. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27999#issuecomment-3460666492 From vyazici at openjdk.org Wed Oct 29 10:04:33 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 10:04:33 GMT Subject: Integrated: 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 11:42:20 GMT, Volkan Yazici wrote: > [JDK-6636319] introduced `ArrayEncoder`, composed of _only_ `encode` method. Later on [JDK-8054307] (JEP 254: Compact Strings) removed all its usages. This method can safely be removed, hence this PR. Confirmed that `tier1-2` tests are clear on several platforms after changes. > > [JDK-6636319]: https://bugs.openjdk.org/browse/JDK-6636319 > [JDK-8054307]: https://bugs.openjdk.org/browse/JDK-8054307 This pull request has now been integrated. Changeset: bbe5e83c Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/bbe5e83c3910dc4986a1dccf6fcf31d15710c71d Stats: 293 lines in 9 files changed: 62 ins; 193 del; 38 mod 8363925: Remove unused sun.nio.cs.ArrayEncoder::encode Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/27999 From jpai at openjdk.org Wed Oct 29 10:13:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 10:13:50 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 Hello Volkan, I'm not familiar with this protocol, but the clean up itself looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28012#pullrequestreview-3392545824 From prappo at openjdk.org Wed Oct 29 10:25:59 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 29 Oct 2025 10:25:59 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v4] In-Reply-To: References: Message-ID: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Fix one more occurrence - Merge remote-tracking branch 'jdk/master' into 8370568 - Merge remote-tracking branch 'jdk/master' into 8370568 - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d - Reword for clarity as suggested - Drop to ease upcoming merge from loom repo - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27972/files - new: https://git.openjdk.org/jdk/pull/27972/files/b3297337..32e4c36a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=02-03 Stats: 2165 lines in 89 files changed: 1112 ins; 785 del; 268 mod Patch: https://git.openjdk.org/jdk/pull/27972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972 PR: https://git.openjdk.org/jdk/pull/27972 From prappo at openjdk.org Wed Oct 29 10:26:00 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 29 Oct 2025 10:26:00 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v3] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 09:39:55 GMT, Jaikiran Pai wrote: > Hello Pavel, these changes look OK to me. > > Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text. Moving from "interrupted" to "interrupt" was a slow drift rather than a landslide. I think it's okay to repair it once. _Loom_ is already in and once _structured concurrency_ is in, I don't expect many new occurrences of "interrupt" in the foreseeable future. But you are right, the important bit is the specification, not the code comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27972#issuecomment-3460767516 From jpai at openjdk.org Wed Oct 29 10:29:34 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 10:29:34 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v4] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 10:25:59 GMT, Pavel Rappo wrote: >> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. >> >> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Fix one more occurrence > - Merge remote-tracking branch 'jdk/master' into 8370568 > - Merge remote-tracking branch 'jdk/master' into 8370568 > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d > + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d > + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d > + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d > + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d > + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d > + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d > ... Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392609024 From michaelm at openjdk.org Wed Oct 29 13:23:56 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 29 Oct 2025 13:23:56 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 Looks fine. ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28012#pullrequestreview-3393336213 From prappo at openjdk.org Wed Oct 29 15:39:31 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 29 Oct 2025 15:39:31 GMT Subject: Integrated: 8370568: Refer to Thread.interrupted as "interrupted status" consistently In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo wrote: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. This pull request has now been integrated. Changeset: 28f2591b Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/28f2591bad49c4d1590325c3d315d850ab6bcc7d Stats: 260 lines in 77 files changed: 4 ins; 0 del; 256 mod 8370568: Refer to Thread.interrupted as "interrupted status" consistently Reviewed-by: jpai, rriggs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/27972 From dfuchs at openjdk.org Wed Oct 29 17:26:26 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 29 Oct 2025 17:26:26 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 LGTM. The only other mention of sdp I could find in the sources and test is in [ct.properties](https://github.com/openjdk/jdk/blob/28f2591bad49c4d1590325c3d315d850ab6bcc7d/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct.properties#L668) (javac) but since this file also contains references to corba packages that have long been removed I expect that reference should also remain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28012#issuecomment-3462778460 From bpb at openjdk.org Wed Oct 29 17:44:40 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 29 Oct 2025 17:44:40 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v17] In-Reply-To: References: Message-ID: > 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 17 commits: - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8337143: Minor makefile tweak - ... and 7 more: https://git.openjdk.org/jdk/compare/2f613911...2d4c4deb ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=16 Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From alanb at openjdk.org Wed Oct 29 18:29:27 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 29 Oct 2025 18:29:27 GMT Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win) In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 00:52:18 GMT, Brian Burkhalter 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`. toRealPath is specified to throw if it fails. The error `FileSystemException: Z:\link: The name of the file cannot be resolved by the system` seems okay. So I'm not yet convinced we need to change anything. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28032#issuecomment-3463077817 From bpb at openjdk.org Wed Oct 29 21:23:24 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 29 Oct 2025 21:23:24 GMT Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win) In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 00:52:18 GMT, Brian Burkhalter 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`. I don't think the current behavior is incorrect, but it does not provide the sought for outcome. The fallback path using `resolveAllLinks` appears to find the desired answer in these cases where ` GetFinalPathNameByHandle` itself fails. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28032#issuecomment-3464107901 From sspitsyn at openjdk.org Thu Oct 30 00:06:00 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 30 Oct 2025 00:06:00 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" This looks good to me modulo the comment from Alan. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3396935258 From lmesnik at openjdk.org Thu Oct 30 03:12:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 03:12:46 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: reverted back one test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28030/files - new: https://git.openjdk.org/jdk/pull/28030/files/e132e73f..4eec9c78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28030/head:pull/28030 PR: https://git.openjdk.org/jdk/pull/28030 From lmesnik at openjdk.org Thu Oct 30 03:12:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 03:12:46 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 06:56:56 GMT, Alan Bateman wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> reverted back one test > > test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 28: > >> 26: * @bug 8284161 8303242 >> 27: * @summary Test com.sun.management.ThreadMXBean with virtual threads >> 28: * @requires test.thread.factory != "Virtual" > > This test allows the "main thread" to be a virtual thread so should pass with JTREG_TEST_THREAD_FACTORY=Virtual. Can you re-check your notes as to why this one should be excluded from JTREG_TEST_THREAD_FACTORY=Virtual runs? > > (all the rest looks okay, excluded via ProblemList-Virtual in the loom repo) Yes, it is not failing. I thought to exclude it because it is virtual thread specific. But I agree, it is not complaint with overall approach. I am reverting this test change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28030#discussion_r2476276800 From alanb at openjdk.org Thu Oct 30 06:54:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Oct 2025 06:54:10 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 03:12:46 GMT, Leonid Mesnik wrote: >> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. >> >> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. >> >> The tests that are incompatible with test thread factory are marked with >> test.thread.factory == null >> and the tests that are rather incompatible with virtual threads are makred >> with >> test.thread.factory != "Virtual" > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > reverted back one test Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3397682870 From alanb at openjdk.org Thu Oct 30 08:14:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Oct 2025 08:14:40 GMT Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win) In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 21:20:51 GMT, Brian Burkhalter wrote: > I don't think the current behavior is incorrect, but it does not provide the sought for outcome. The fallback path using `resolveAllLinks` appears to find the desired answer in these cases where ` GetFinalPathNameByHandle` itself fails. We can't fallback unconditionally when GetFinalPathNameByHandle fails. The only reason for this fallback path is for cases where there is a sym link to something that we know doesn't support links. So this is why it is limited to ERROR_INVALID_LEVEL, and even then it is dubious and maybe we need to explore the errors and interop issues further before seeing if anything should be done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28032#issuecomment-3466570757 From kevinw at openjdk.org Thu Oct 30 11:43:29 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 30 Oct 2025 11:43:29 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 03:12:46 GMT, Leonid Mesnik wrote: >> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. >> >> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. >> >> The tests that are incompatible with test thread factory are marked with >> test.thread.factory == null >> and the tests that are rather incompatible with virtual threads are makred >> with >> test.thread.factory != "Virtual" > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > reverted back one test Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3399147490 From lmesnik at openjdk.org Thu Oct 30 15:38:19 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 15:38:19 GMT Subject: Integrated: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" This pull request has now been integrated. Changeset: ed36b9bb Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/ed36b9bb6f3d429db6accfb3b096e50e7f2217ff Stats: 29 lines in 13 files changed: 15 ins; 1 del; 13 mod 8370851: Mark hotspot and jdk tests incompatible with test thread factory Reviewed-by: alanb, kevinw, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28030 From bpb at openjdk.org Thu Oct 30 15:53:45 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Oct 2025 15:53:45 GMT Subject: RFR: 8368165: (fs) Path.toRealPath does not perform correctly for symbolic links in a mapped drive (win) In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 08:11:34 GMT, Alan Bateman wrote: > We can't fallback unconditionally when GetFinalPathNameByHandle fails. Right, I was uncertain about this which is why I commented above that "It might be that falling back to the slow path should be limited to a certain subset of error codes". ------------- PR Comment: https://git.openjdk.org/jdk/pull/28032#issuecomment-3468709414 From alanb at openjdk.org Thu Oct 30 18:48:23 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Oct 2025 18:48:23 GMT Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v20] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:01:10 GMT, Per Minborg 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/util/List.java line 1200: > 1198: > 1199: /** > 1200: * {@return a new lazily computed list with the provided {@code size}} A minor comment here is that "of the given size" might be a bit clearer than "with the provided size". src/java.base/share/classes/java/util/List.java line 1240: > 1238: * function used to compute elements only so long as there are uncomputed elements > 1239: * after which the computing function is not strongly referenced > 1240: * anymore and may be collected. I think it's okay to say that the computing function is kept strongly reachable until at least all elements have been computed. I'm less sure about the second part being normative text and wonder if it would be better to move that part to an implNote. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2479172995 PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2479168408